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RECOGNIZE  RISKS  EARLY 


SOFTWARE  ACQUISITION 
MANAGEMENT 


llolumes  have  been  written  about 
u  acquisition  management,  and 
I  part  of  that  mass  of  information 
I  discusses  software  management. 
The  problem  with  software  acquisi¬ 
tion  management  information  is  that 
it  is  voluminous  and  scattered  all  over. 

In  law  school,  some  of  the  most 
popular  little  books  are  the  “nutshell" 
series  published  by  West  Publishing 
Co.:  Contract  Law  in  a  Nutshell,  etc. 
The  objective  of  this  article  is  to  pro¬ 
vide  you  with  a  nutshell  capsule  sum¬ 
mary  of  information  you  need  for  soft- 
vvare  acquisition  management.  I  hope 
you  find  it  useful. 

Why  Software  Management 
Is  Difficult 

Software  management  is  difficult 
because  of  uncertainty  and  risk  (big 
surprise?).  It's  usually  very  difficult  to 
recognize  software  risks  as  they  sur¬ 
face.  You  generally  see  sofnvare  risk 
later,  sometimes  much  later,  when  it  is 
no  longer  a  risk  but  has  become  a 
problem  and  costly  or  even  impos¬ 
sible  to  correct.  But,  you  should  see  it 
and  plan  for  it  much  earlier.  The  soft¬ 
ware  risk  driven  problems  are  usually 
management,  not  technical.  During 
acquisition,  we  seldom  consider  the 
things  that  “kill"  us  later.  We  wear 
cost-proposal  blinders.  Acquisition 


Mr.  Dobbins  is  a  Professor  of  Sys¬ 
tems  Management  at  the  Defense  Sys¬ 
tems  Management  College  and  Course 
Director  for  the  Management  of  Soft¬ 
ware  Acquisition  course. 
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James  H.  Dobbins 

managers  need  to  do  eight  things 
better. 

Eight  Cost-Proposal  Blinders 

1 .  Use  metrics  properly.  Understand 
metrics  implications. 

2.  Understand  the  implications  of 
software  process  capability  maturity. 

3.  Understand  when  we  do  and  don’t 
need  an  independent  verification  and 
validation  contractor. 

4.  Understand  system  performance 
implications  of  software  quality. 

5.  Don’t  let  low  software  cost  blind 
us  to  its  potential  effect  on  the  system. 

6.  Do  software  requirements  a  lot 
better. 


7.  Learn  how  to  build  visibility 
requirements  into  the  RFP/Contract. 

8.  Learn  how  to  establish  sensible 
software  source-selection  criteria. 

Twenty-three  Sources  of 
Software  Risk  and  Uncertainty 

Havingdone  those  eight  things  bet¬ 
ter,  acquisition  managers  need  to  un¬ 
derstand  the  following  23  sources  of 
software  risk  and  uncertainty. 

1 .  Government  and  contractor  lack 
of  understanding  of  the  effect  of  soft¬ 
ware  process  maturity. 

2.  Lack  of  software  experience  in  top 
management.  Ignorance  of  the  law  is 
no  excuse. 

3.  Lack  of  understanding  of  when, 
how  and  what  to  measure  (software 

metrics). 

4.  Lack  of  understanding  of 
how  best  to  get  current  infor¬ 
mation/visibility. 


During  acquisition, 
we  seldom  consider 
the  things  that  “kill*’ 
us  later.  We  wear  cost- 
proposal  blinders. 
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5.  Lack  of  understanding  of  how  to 
use  measurement  (metric)  informa¬ 
tion. 

6.  Lack  of  understanding  of  full  spec¬ 
trum  of  contractor  testing. 

7.  Lack  of  understanding  of  how  to 
utilize  the  test  concept  in  software 
fully. 

8.  Lack  of  understanding  of  the  fun¬ 
damental  and  significant  differences 
between  software  and  hardware  con¬ 
cepts  for  common  terms  such  as  reli¬ 
ability  and  availability. 

9.  Failure  to  incorporate  proper  rigor 
and  knowledge  into  source-selection 
criteria. 

10.  Lack  of  understanding  of  how  to 
plan  for  software  risks  so  the  risks  stay 
risks  instead  of  becoming  problems. 

11.  Lack  of  understanding  that  soft¬ 
ware  isn’t  magic. 

12.  Lack  of  understanding  how  soft¬ 
ware  fits  into  the  system  engineering 
process. 

13.  Failure  to  understand  software  ar¬ 
chitecture  and  the  effects  of  changes. 
Why  you  can  add  a  window  to  the  top 
floor  of  the  nine-story  software  build¬ 
ing,  but  you  can’t  add  a  basement. 

14.  Lack  of  understanding  that  soft¬ 
ware  engineering  is  a  discipline;  a 
process. 

15.  Lack  of  understanding  of  the  im¬ 
plications  of  insufficient  time  allocated 
for:  Software  Requirements,  Software 
Design,  Concurrent  Engineering,  In- 
Process  Quality  Analysis,  Design  for 
Reuse,  PDR/CDR,  Error  Correction, 
Error,  Analysis  and  Error  Prevention. 

1 6.  Lack  of  understanding  why  highly- 
structured  languages  like  Ada  are  good 
for  the  DOD  software  engineering  en¬ 
vironment  where  most  developers  are 
process  immature. 

17.  Lack  of  understanding  that  good 
software  development  is  event  driven, 
not  schedule  driven. 

IS.Lack  of  understanding  of  the  soft¬ 
ware  acquisition  life-cycle  activities 
and  their  purpose. 

19.  Abdication  of  decision  making  to 
contractors  because  we  don’t  want  to 
deal  with  software  issues. 

20.  Lack  of  trust  of  good  contractors. 

21.  Too  much  trust  in  less-than-com- 
petent  contractors. 


22.  Failure  to  make  sure  you  have 
systems  engineering  capability  in  the 
program  office  staff. 

23.  Letting  esoteric  technology  issues 
cloud  your  software  decision  making 
ability. 

’Twenty-nine  Rules  for 
Managing  Software  Acquisition 

The  29  rules  for  managing  software 
acquisition  are  as  follows: 

1 .  Learn  not  to  be  afraid  of  software. 
Put  your  arm  around  it  and  give  it  a 
hug. 

2.  Understand  and  manage  the  soft¬ 
ware  development  process. 

3.  Understand  the  greatest  strength 
of  software:  flexibility. 

4.  Understand  thegreatestweakness 
of  software:  flexibility. 

5.  Learn  and  recognize  the  software 
issues  that  can  kill  you. 

6.  Understand  that  the  software  de¬ 
velopment  process  is  manageable  as 
is  any  engineering  process. 

7.  Learn  the  importance  of  software 
configuration  mana^ment. 

8.  Learn  the  different  kinds  of  soft¬ 
ware  tests,  and  when  and  how  they 
can  be  used  best. 

9.  Let  the  requirements  definition  pro¬ 
cess  happen.  Don’t  close  it  too  soon. 
Keep  the  user  involved.  Understand 
how  to  do  good  prototyping. 

10.  Learn  that  software  requirements 
changes  after  critical  design  review 
(CDR)  can  kill  your  system  cost,  sched¬ 
ule  and  performance.  Don’t  let  the 
user  or  contractor  jerk  you  around 
after  CDR.  Don’t  jerk  the  contractor 
around  after  CDR. 

1 1 .  Recognize  that  a  software  prelimi¬ 
nary  design  review  (PDR)  or  C DR  done 
too  early  might  as  well  not  be  done  at 
all. 

12.  Recognize  that  once  you  are  be¬ 
yond  the  software  B5  spec  (software 
requirements  spec),  the  user  is  prob¬ 
ably  useless  in  reviewing  software 
documents. 

1 3 .  Never  underestimate  what  a  good, 
process-mature,  software  contractor 
can  do  for  you  to  pull  you  out  of  a  cost/ 
schedule/performance  hole. 

14.  Never  forget  that  a  process-imma¬ 


ture  software  contractor  will  be  virtu¬ 
ally  useless  in  pulling  you  out  of  a 
cost/schedule/performance  hole. 

15.  Never  forget  that  if  you  hire  a  pro¬ 
cess-immature  software  contractor, 
your  success  or  failure  on  the  contract 
will  happen  in  spite  of  your  skill  as  a 
program  manager,  not  because  of  it. 

16.  Never  forget  that  software  has  no 
production  cycle.  The  first  article  is 
“it”  and  if  you  fail,  you’re  dead  in  the 
water. 

1 7.  Always  think  risk  at  every  step  of 
the  software  acquisition  process.  Re¬ 
member  risk  is  always  a  potential. 
When  the  risk  event  happens,  it  has 
become  a  problem. 

1 8. Trying  to  manage  performance  out¬ 
come  is  a  blueprint  for  disaster.  Learn 
to  manage  process. 

19. Always  think  software  support 
(PDSS)  at  every  step  of  the  software 
acquisition  process. 

20. Learn  that  for  unprecedented  sys¬ 
tems,  the  waterfall  model  of  software 
development  doesn’t  work.  Don’t  let 
DoD-STD-2167A  drive  you  over  that 
waterfall  in  a  barrel. 

2 1  .Learn  that  for  unprecedented  sys¬ 
tems,  you  must  prototype  software  as 
you  have  to  prototype  hardware.  It 
takes  time,  but  that’s  the  way  you 
learn  what  requirements  are.  Let  this 
happen  and  move  PDR/CDR  if  you 
have  to. 

22.  Learn  to  get  your  metric  informa¬ 
tion  and  software  status  from  your 
computer  resource  working  group 
(CRWG)  and  monthly  reviews,  not 
just  in  CDRLs  which  take  too  long  to 
produce.  The  data  are  too  old  by  the 
time  you  get  it. 

23.  Get  software  expertise  and  sys¬ 
tems  engineering  expertise  in  your 
program  office,  even  if  only  on  a  con¬ 
sulting  basis. 

24.  Understand  that  commercial  off- 
the-shelf  (COTS)  software  seldom 
works  in  custom-designed  unprec¬ 
edented  systems,  especially  in  em¬ 
bedded  system  software. 

25.  Never  incorporate  a  Non-Devel¬ 
opment  Item  (NDI)  or  COTS  software 
in  a  system  without  first  having  the 
contractor  evaluate  the  feasibility  in 
the  intended  environment.  It  seldom 
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works  as  well  in  the  intended  environ¬ 
ment  as  you  had  hoped. 

26. Never  force  a  certain  technology, 
like  object-oriented  design,  on  a  con¬ 
tractor  unless  you  really  need  it.  It 
can  be  like  asking  a  toddler  to  drive 
an  Indy  500  race  car. 

27.  Understand  that  if  you  design  for  ^ — > 

reuse,  it  will  cost  more.  The  payback  ^ - ^ 

comes  later,  possibly  on  the  next 
program. 

28.  Learn  to  use,  and  tailor,  softw'are 
standards,  including  industry  stan¬ 
dards.  Read  them.  Understand  what 
they  require.  If  you  don’t  need  a  part, 
tailor  it  out. 

29.Set  up  and  use  a  Computer  Re¬ 
sources  Working  Group.  Make  sure 
they  produce  and  keep  up-to-date  your 
Computer  Resources  Life -Cycle  Man¬ 
agement  Plan  (CRLCMP).  Watch  your 
interfaces.  Get  the  Interface  Control 
Working  Group  (ICWG)  in  place  early 
and  use  them.  Make  the  CRWG  inter¬ 
face  with  the  ICWG  and  other  work¬ 
ing  groups  (WGs). 

Recognizing  Software  Risks 

Remember  that  risks  are  always  a 
future  consideration.  Once  a  risk  event 
happens,  it  is  no  longer  a  risk;  it  is  a 
problem.  How  far  in  the  future  you 
can  spot  a  risk  is  a  function  of  how  well 
you  do  measurement  and  strategic 
planning.  We  look  at  risk  in  terms  of 
probability  and  severity.  If  low  sever¬ 
ity,  you  may  not  care  if  it  occurs.  If 
h  igh  severity,  you  had  better  care  a  lot. 

If  high  severity,  but  low  probability, 
you  should  always  get  nervous.  If  the 
probability  of  a  high-severity  risk  is 
not  zero,  you  always  worry  about  when 
your  number  is  coming  up.  You  must 
build  fall-back  positions  into  your  stra¬ 
tegic  planning.  There  are  questions 
you  need  to  ask  yourself  about  differ¬ 
ent  types  of  software  risk. 

Feasibility  Risks:  Can  we  do  the 
job?  Is  the  technology  there?  Can 
this  contractor  do  the  job?  How 
much  experience  does  he  have?  Is 
the  task  unprecedented  for  this 
contractor?  Do  you  know  all  the 
requirements?  How  sure  are  you? 

Are  the  users  involved  in 


Remember  that  risks 
are  always  a  future 
consideration.  Once  a 
risk  event  happens,  it  is 
no  longer  a  risk;  it  is  a 
problem. 

requirements  definition?  Do  you 
have  to  prototype?  Has  the 
contractor  ever  done  prototyping? 
Should  you  use  an  acquisition 
strategy  of  evolutionary  acquisi¬ 
tion? 

Engineering  and  Producibility:  Do 

you  have  to  do  evolutionary 
acquisition  (requirements  not  fully 
determinable  for  Block  1 )?  Can  you 
produce  a  working  system  for  Block 
I?  Does  the  contractor  have 
requisite  skills? 

Do  you  have  to  supplement  the 
contractor  with  a  directed 
subcontractor?  What  is  the 
contractor’s  process  capability 
maturity?  Do  you  need  to  do  a 
Software  Capability  Evaluation 
(SCE)  or  equivalent?  Do  you  have 
a  means  for  doing  a  software  pre¬ 
award  audit?  Have  you  factored 
these  possibilities  into  your  source- 
selection  criteria?  Who  can  you  get 
to  do  the  audit?  What  is  the 
contractor’s  meaningful  experience 
with  the  language  (Ada)?  In  what 
environments?  Does  the  schedule 


give  the  contractor  enough  time  for 
requirements  definition? 

Are  you  and  the  contractor  working 
together  to  minimize  post-CDR 
requirements  changes?  What  kind 
of  communications  processes  have 
you  set  up  with  the  contractor  to 
address  and  control  technical 
issues?  Does  the  schedule  give  the 
contractor  enough  time  for  design? 
Do  you  understand  the  contractor’s 
software  test  program?  Is  it 
adequate?  Do  you  and  the 
contractor  understand  which 
metrics  the  contractor  is  using  and 
the  utility  of  the  information?  Does 
the  contractor  management  use  the 
information?  Are  meaningful 
metrics  being  used  in  all  life-cycle 
phases? 

How  does  the  contractor  select  and 
use  Computer-Aided  Software 
Engineering  (CASE)  tools?  Which 
ones?  Why  were  they  chosen?  Are 
they  force  multipliers?  Is  the 
contractor  dependent  on  a 
subcontractor?  How  well  do  they 
manage  subcontractors?  How  do 
you  know?  What  evidence?  Do  you 
understand  the  contractor’s 
software  quality  process?  Do  you 
understand  the  contractor’s 
software  configuration  man¬ 
agement  process? 


Cost  Risks:  Do  you  expect  the 
contractor’s  cost  proposal  to  be 
accurate?  Why?  What  will  you  do  if 
it  isn’t?  What  if,  by  the  time  you  hit 
CDR.you  are  seeinga  40-60  percent 
overrun?  What  are  your  fail-back 
options?  Plan  for  these  well  in 
advance,  because  this  is  likely  to 
be  what  happens.  Cost  estimates 
on  unprecedented  systems  are 
usually  a  lot  lower  than  eventual 
reality.  We  simply  don’t  know  how 
to  do  it  better. 

One  thing  that  helps  is  a  well-written 
Statement  of  Work  (SOW).  Do  your 
strategic  planning  early.  Plan  for 
cost  overruns  and  alternate  actions 
you  must  take.  Make  sure  you 
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collect  the  necessary  metrics  often 
to  spot  potential  cost  overruns  as 
far  in  advance  as  possible.  Always 
know  the  difference  between 
requirements  and  desirements. 
Never  cut  requirements;  just 
desirements. 

Rules  to  Follow 

Follow  the  next  17  rules  to  keep 
software  contracting  from  “biting”  you: 

1.  Invoke  the  desired  standards 
(D0D-STD-2167A.  DoD-STD-2168, 
MILSTD-1521B  and  DoD-STD-973. 
or  industry  standards  like  lEEE-STD- 
982. 1 ).  Invoke  these  standards  in  Sec¬ 
tion  3  of  the  SOW,  and  anywhere  else 
you  need  them,  not  just  Section  2. 
Tailor  them  where  necessary:  never 
invoke  “blanket”  standards.  Always 
know  what  you  are  imposing,  and 
what  you  are  tailoring.  Read  the 
standards. 

2.  Watch  for  pitfalls  in  chaining  stan¬ 
dards  between  specification  docu¬ 
ments.  Treat  each  specification  as  a 
stand-alone  in  terms  of  standards  in¬ 
vocation. 

3.  If  you  want  metrics,  ask  for  them. 
If  you  want  specific  metrics  used,  say 
so  in  the  RFP/Contract. 

4.  If  you  want  metric  data  provided, 
say  when  and  how  and  how  often. 

5 .  Ask  the  contractor  to  describe  their 
own; 

— Software  engineering  environment, 
including  CASE  tools 
— Software  management,  including 
subcontractor  management  process 
— Software  development  processes 
and  tools 

— Error  correction/analysis  process 
— Software  test  and  evaluation 
process:  all  of  it,  at  each  life  cycle 
phase. 

6.  If  you  want  to  see  CASE  tool  out¬ 
put,  say  so.  What,  when,  how  and 
how  often. 

7.  If  you  want  specific  processes  used, 
say  so. 

8.  If  you  want  software  root  cause 
analyses  instead  of  bug  fixes,  say  so. 
Allow  time  for  it.  Why  would  you  want 
this?  Because  the  industry  average  is 
that  14.7  percent  of  software  error 


(bugs)  fixes  are  bad  fixes,  and  fast-bug 
fixing  can  turn  your  software  into  spa¬ 
ghetti  code  overnight,  and  you  won’t 
have  enough  money  left  to  recover. 
Remember  software’s  biggest  weak¬ 
ness  —  flexibility. 

9.  When  you  know  what  you  want, 
make  it  part  of  the  source-selection 
criteria.  Use  the  criteria  to  drive  you  to 
the  most  capable,  not  just  the  cheap¬ 
est,  contractor. 

A  lowest-price  software  contractor 
may  be  your  most-expensive  choice. 
It  may  be  your  best  choice.  It  Depends. 
It  depends  on  their  software  engineer¬ 
ing  and  quality  processes,  metrics, 
use  of  CASE  tools,  and  their  process 
capability  maturity.  If  they  are  pro¬ 
cess  capability  immature,  don’t  know 
how  to  use  CASE  tools,  and  are  low 
bidder,  run,  don’t  walk,  to  the  next 
contractor  in  line.  You’ll  be  sorry  if 
you  don’t.  When  you  get  the  propos¬ 
als,  read  them  critically.  Read  between 
the  hype,  between  the  chest-pound¬ 
ing,  and  get  to  the  real  meat.  "The  rest 
they  must  include  because  we  expect 
it.  But,  listen  to  what  they  say  they 
really  do.  Then  do  a  pre-award  audit 
or  software  capability  evaluation. 

10.  In  proposal  responses: 

— Read  the  Software  Development 
Plan  (SDP) 

— Read  the  Quality  Plan 
— Read  the  Configuration  Man¬ 
agement  Plan. 

— Read  the  Test  Plan 
— Read  the  Software  Subcontractor 
Management  Plan. 

11.  Pay  close  attention  to  what  they 
say  about  subcontractor  management. 
Ask  for  their  subcontractor  manage¬ 
ment  plan. 

12.  Watch  out  for  data  rights  issues. 

13.  Look  for  front-end  quality  pro¬ 
cesses,  like: 

— Design  and  code  inspections 
— Complexity  analysis  CASE  tools 
— Requirements  generator  CAS E  tools 
— Code  generator  CASE  tools. 

14. CAUTION:  If  they  use  the  Integra¬ 
tion  and  System  Test  phases  as  the 
primary  time  to  find  and  fix  software 
bugs,  your  system  very  probably  will 
be  late,  will  overrun  cost,  and  prob¬ 
ably  will  have  unsatisfactory  perfor¬ 


mance  no  matter  what  you  do.  If  they 
skip  Unit  Test,  expect  big  problems 
later,  but  ones  that  are,  perhaps,  not 
found  until  a  disaster  during  opera¬ 
tional  test  or  actual  use  —  big  costs, 
and  possible  injuries. 

15.  Look  for  whether  they  design  for 
maintainability. 

1 6.  If  they  say  they  use  a  development 
process,  like  design  and  code  inspec¬ 
tions,  go  back  and  ask  them  to  de¬ 
scribe  it  and  how  they  use  the  results. 
Many  contractors  give  lip-service  to 
good  processes  but  don’t  understand 
well  enough  to  use  them  properly. 
Don’t  ever  forget  that  no  matter  how 
good  a  proposal  looks,  more  than  80 
percent  of  the  DOD  contractors  are 
software  process  capability  immature 
(Initial  level  on  SEI  scale).  It  is  one  of 
the  most,  if  not  the  most,  serious  hid¬ 
den  risks  we  face  in  contracting  for 
software. 

17.  CAUTION:  Software  cost  models 
are  everywhere:  COCOMO,  REVIC, 
PRICE-S,  etc.  None  of  the  results  are 
worth  anything  if  you  can’t  get  a  good 
estimate  of  software  size.  All  the  mod¬ 
els  are  dependent  and  results  are  bi¬ 
ased  by  software  size.  Software  size  is 
a  sensitive  parameter.  Therefore,  for 
an  unprecedented  system,  don’t  ex¬ 
pect  contractors  to  provide  accurate 
cost  proposals.  They  can’t.  Neither 
can  we.  Nor,  can  anyone  else.  The 
best  software  cost  estimate  will  come 
from  a  technically-capable  and  pro¬ 
cess-mature  contractor  with  a  good 
database,  who  collects  good  metrics, 
and  who  had  experience  a  few  times. 
That  probably  means  a  contractor  at 
the  Defined  level  on  the  SEI  scale.  The 
process  capability  immature  contrac¬ 
tors  don’t  have  good  databases,  or 
databases  with  valid  data  for  estimat¬ 
ing  cost.  Even  if  they  have  a  database, 
their  immaturity  biases  the  cost  data. 

What’s  All  This  Stuff  About 
Metrics? 

The  DoDI  5000.2  requires  using 
metrics  in  software  management.  It 
doesn’t  say  how,  which,  when  or  what 
for.  That’s  up  to  you.  Congratulations! 
Metrics  are  only  a  number.  Their  only 
utility  is  in  understanding  the  infor- 
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mation  baggage  that  goes  _ - 

along  with  the  number:  the  implica¬ 
tions:  what  they  tell  you  that  helps  you 
make  a  decision.  They  answer  a  ques¬ 
tion  for  which  you  need  an  answer. 
Don’t  look  at  metrics  as  isolated  things: 
think  in  terms  of  sets  of  data  that  you 
use  together  to  get  a  total  picture  of 
issues  which  need  decisions. 

Computing  metrics  for  its  own  sake , 
or  because  something  is  measurable, 
or  just  to  check-off  a  DoDl  5000.2 
paragraph  is  a  waste  of  time  and 
money.  Good  contractors  know  this. 
Process  capability  immature  contrac¬ 
tors  do  not.  Good  contractors  com¬ 
pute  meaningful  metrics  as  a  matter  of 
course  because  it  helps  them  control 
their  processes  and  make  good  deci¬ 
sions.  They  use  metrics  as  a  tool  to 
achieve  continuous  improvement  in 
their  processes  and  control  their  tech¬ 
nical  efforts  and  costs.  Process-imma¬ 
ture  contractors  compute  metrics  be¬ 
cause  the  government  makes  them; 
they  whine,  complain  about  the  cost, 
and  most  don’t  understand  implica¬ 
tions  of  measurements  they  do  take. 
They  look  at  metrics  as  an  unneces¬ 
sary  cost-driver. 

Two  fundamental  types  of  metrics 
exist.  These  are  generally  classified  as 
management  metrics  and  quality 
metrics.  Don’t  be  confused  by  the  no¬ 
menclature.  Both  are  important  to 
management  and  to  technical 
pjersonnel. 


If  the  slope  does  not 
level  off  to  a  very  low 
value  by  and  after  CDR» 
youVe  at  big-time  risk 
for  meeting  your 
threshold  (forget  about 
the  objective).  This 
Junkyard  dog  can  bite 
hard.  When  it  does, 
effects  often  are 
unrecoverable. 


Most  metrics  are  utilized  best  when 
presented  as  trend  data  as  opposed  to 
point-in-time  data.  There  are  excep¬ 
tions  but  this  is  a  good  general  rule. 

Metrics  You  Need  for  Any 
Development  Program 

Requirements  Volatility.  How  rap¬ 
idly  are  changes  being  made  over  time 
to  software  requirements?  What  is  the 
rate  of  change?  Plot  the  cumulative 
number  of  changes  over  time  and 
watch  the  slope  of  that  line.  Do  it  for 
the  entire  program,  and  for  each  Com¬ 


puter  Software  Configuration  Item 
(CSCl)  independently.  If  the  slope 
does  not  level  off  to  a  very  low 
value  by  and  after  CDR,  you’re  at 
big-time  risk  for  meeting  your 
threshold  (forget  about  the  objec¬ 
tive).  This  junkyard  dog  can  bite  hard. 
When  it  does,  effects  often  are  unre¬ 
coverable.  It  throws  you  almost  auto¬ 
matically  into  a  cost-and-schedule 
problem.  You  and  your  contractor 
must  manage  this  from  early  on. 

Software  Size  and  Size  Growth  Over 
Time.  Disaggregate  the  data.  Don’t 
just  look  at  total  size,  but  also  at  the 
size  dynamics  of  each  component 
CSCI:  also,  each  type  of  code  (func¬ 
tion  and  language).  Keep  track  of 
these  values  separately  for  New  Code, 
Reused  Code  andModified Code.  Un¬ 
derstand  the  cost  implication  of  chang¬ 
ing  the  original  projections  of  new, 
modified,  and  reused  code.  The  total 
lines  of  code  may  not  change,  but  if 
new  code  goes  up,  and  reused  code 
goes  down,  the  cost  will  go  up  because 
it  is  more  expensive  to  build  and  test 
new  code  than  to  reuse  old  code.  Take 
continuous  size  projections  at  all  life- 
cycle  phases.  The  initial  contractor 
estimates  are  usually  low,  often  con¬ 
siderably  low.  You  must  match  size 
growth  projections  against  hardware 
capacity. 

Personnel.  Same  sort  of  thing  as 
software  size.  Track  separately  the 
changes  for  total  personnel,  but  also 
the  mix  of  experienced  and  inexperi¬ 
enced.  Watch  for  changes  near  major 
review  times. 

Computer  Attributes.  What  is  the 
capacity?  How  is  the  software  size 
growth  affecting  the  hardware  capac¬ 
ity?  Require  at  least  50  percent  re¬ 
serve  memory.  Does  the  slope  of  the 
software  growth  curve  make  you  ner¬ 
vous?  If  the  memory  reserve  capacity 
drops  below  30  percent,  you  are  in 
trouble.  It’s  no  longer  a  future  tense; 
no  longer  a  risk:  it  has  become  a  prob¬ 
lem.  \Vhat\sthe  processor  speed?  Can 
the  computer  speed  match  software 
requirements? 
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Software  Volatility.  Don't  worry 
about  counting  how  many  trouble  re¬ 
ports  you  have  open  today.  It’s  use¬ 
less  information.  Rather,  what  is  the 
rate  of  change  for  the  software  after 
Unit  Test?  Plot  cumulative  changes 
(trouble  reports  and  requirements 
changes)  over  time  for  the  whole  sys¬ 
tem  and  for  each  CSCl  independently; 
also  by  trouble  report  severity  class. 
For  trouble  reports,  at  the  midpoint  of 
the  computer  testing  period,  or  earlier, 
the  slope  of  this  cumulative  curve 
should  change  rapidly  and  begin  to 
approach  zero  as  an  asymptote.  If  it 
doesn’t  start  doing  that  by  the  mid¬ 
point,  you  are  in  trouble.  Get  with 
your  contractor  and  understand  the 
problem.  Is  it  in  one  CSCI,  or  is  it 
system  wide?  Probably  one  or  two 
CSCI.  Work  out  a  plan  of  recovery. 

Complexity.  Understand  software 
complexity,  especially  Cyclomatic 
Complexity  (also  called  McCabe’s 
Complexity).  It  is  a  very  powerful 
metric.  Use  a  CASE  tool  to  help  ana¬ 
lyze  the  code.  Many  analyzers  can 
analyze  Ada.  If  you  have  one  that 
does,  you  can  analyze  the  design  as 
well  as  the  code  if  you  are  using  Ada  as 
a  program  design  language  (PDL).  Un¬ 
derstand  that  when  you  compute  the 
complexity  number,  this  unitless  num¬ 
ber  has  1 1  implications. 

Eleven  Implications  of  the 
Complexity  Number 

1 .  It  is  the  exact  number  of  indepen¬ 
dent  paths  through  a  software  CSU 
(module). 

2.  It  is  the  minimum  number  of  test 
cases  you  must  have  to  test  each  part 
of  the  module  at  least  once,  assuming 
the  programmer  recognizes  the  inde¬ 
pendent  paths  and  develops  separate 
tests  for  each  independent  path.  (Some 
of  the  CASE  tools  automatically  high¬ 
light  the  independent  paths,  andauto- 
matically  compute  the  test  conditions 
you  need  to  test  that  path.  All  the 
programmer  must  do  is  copy  the  test 
conditions  into  the  tests  written.) 

3.  If  the  number  goes  above  10  for  a 
module,  the  module  begins  to  be  er¬ 
ror-prone. 


4.  The  higher  than  10  the  module 
complexity  number  is,  the  higher  the 
risk  to  the  system  from  that  module. 

5.  If  the  complexity  for  several  mod¬ 
ules  goes  above  30,  get  somewhat 
nervous  and  take  corrective  action. 

6.  If  the  complexity  for  several  mod¬ 
ules  goes  above  40.  get  really  nervous 
and  take  strong  corrective  action. 

7.  If  the  complexity  for  several  mod¬ 
ules  goes  above  50,  panic.  A  majority 
of  the  module  paths  will  not  be  tested 
in  Unit  Test,  or  any  later  test;  there¬ 
fore,  a  significant  percentage  of  the 
software  will  be  delivered  completely 
untouched  by  any  test.  This  is  an 
enormous,  often-hidden  risk  to  your 
system,  especially  if  software  failure 
could  have  life-threatening  conse¬ 
quences. 

8.  Most  process  capability  immature 
contractors  don’t  understand  anything 
about  software  complexity. 

9.  If  a  high-complexity  module  is  in  a 
critical  path,  especially  a  safety  criti¬ 
cal  path,  it  is  a  time  bomb  waiting  to 
explode. 

10.  Look  at  the  complexity  values  for 
the  entire  system,  and  for  each  CSCI. 
Compute  the  average  complexity  but 
also  look  at  the  complexity  distribu¬ 
tion  curve  (a  histogram).  The  average 
complexity  can  be  deceiving.  Look  at 
how  the  module  complexity  values 
are  distributed  from  lowest  to  highest 
values. 

11.  During  computer-based  testing, 
have  the  contractor  compute  the  com¬ 
plexity  and  get  complexity  graphs,  be¬ 
fore  and  after  each  module  change, 
intended  to  fixa  trouble  report.  This  is 
to  ensure  the  change  did  not  damage 
the  module  structure  and  drive  rp  the 
complexity.  This  lengthens  the  life¬ 
time  utility  of  the  module  and  lowers 
its  total  life-cycle  cost. 

Software  Reliability.  Watch  out  for 
this  one.  Make  sure  you  understand 
the  implications.  Hardware  reliability 
is  a  well-understood,  valid  and  useful 
discipline.  It  is  important  in  under¬ 
standing  maintainability  issues  and 
spare-parts  provisioning.  This  reliabil¬ 
ity  is  usually  computed  as  a  mean 
time  between  failure  (MTBF)  or  mean 


time  to  next  failure  (MTTF).  These 
values  have  real  meaning  for  hard¬ 
ware.  and  it  says  something  about  the 
hardware  itself. 

The  MTBF  is  a  measure  of  the  ex¬ 
pected  time  between  failures  of  sys¬ 
tem  components.  Ifyou  have  a  fighter 
aircraft  MTBF  of  10  hours,  and  your 
average  mission  duration  is  20  hours, 
you  will  not  be  able  to  fly  a  mission. 
We  need  this  information  for  hard¬ 
ware  to  determine  when  to  expect  to 
change  the  hardware.  We  change 
hardware  to  get  it  back  to  its  original 
condition,  because  it  breaks.  After 
you  swap  out  the  broken  part,  the  old 
value  of  MTBF  is  still  good. 

For  software,  MTBF  doesn’t  mean 
anything  except  in  a  gross  sense.  It 
may  not  be  telling  you  anything  mean¬ 
ingful  about  the  software.  There  are 
many  software  reliability  models  that 
have  been  developed  and  work  just 
like  the  hardware  models.  They  are 
statistical  Bayesian  or  Poisson  mod¬ 
els.  They  compute  MTBF.  which  is 
supposed  to  be  a  measure  of  the  ex¬ 
pected  time  between  failures.  If  you 
have  an  MTBF  of  10  hours,  what  does 
this  mean  forsoftware?  Isittellingyou 
anything  about  the  software  itself? 
Software  doesn’t  break.  You  never 
change  software  to  get  it  back  to  its 
original  condition.  Once  you  change 
software,  the  prior  MTBF  measure  is 
no  good. 

From  where  does  the  data  for  soft¬ 
ware  MTBF  come?  It  comes  from 
testing  and  operational  use.  Suppose 
you  develop  a  mediocre  test  and  run 
the  software,  and  you  get  a  certain 
number  of  errors.  You  enter  this  data 
into  the  reliability  model  and  get  a 
number  that  you  think  represents  the 
reliability  of  the  software  being  tested. 
Now  develop  a  different,  more  strin¬ 
gent  test  and  repeat  the  process.  You 
get  a  different  number  of  errors  and, 
consequently,  a  different  reliability 
number — same  software,  same  model. 
Are  you  measuring  the  reliability  of 
the  software  or  the  test  you  wrote? 
Once  you  know  what  data  condition 
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Process  capability  immature  con¬ 
tractors  often  have  not  heard  of  soft¬ 
ware  inspections;  if  they  ha\'e.  they  do 
not  know  how  to  do  them  properly,  or 
how  inspections  can  help.  All  they  see 
is  the  cost,  not  life-cycle  payback  and 
not  quality  drivers. 

If  you  do  good  human  test¬ 
ing,  your  computer-based  test¬ 
ing  processes  will  be  con¬ 
trolled,  manageable,  and  will 
give  the  management  flexibil¬ 
ity  needed.  You  can  recognize 
when  you  have  tested  enough 
by  the  slope  on  the  cumulative 
error  detection  graphs.  Without 
human  testing,  all  bets  are  off. 
You  may  be  in  a  scrap  continu¬ 
ously  (and  don’t  forget  the  14.7 
percent  bad  fixes);  the  com¬ 
plexity  may  grow  continuously 
and  exponentially;  and,  you  will  test 
until  there  is  no  time,  money  or  both, 
and  hope  for  the  best  to  meet  the 
threshold. 


causes  an  error  to  manifest  itself,  you 
can  cause  the  e'-or  to  happen  as  often 
as  you  want  by  recreating  that  envi¬ 
ronment.  Software  is  data  environ¬ 
ment  responsive,  and  it  reacts  to  data 
environments. 

It  will  not  fail  until  it  is  asked  to  do 
something  it  was  not  properly  designed 
to  do.  Until  you  hit  that  condition,  it 
works  fine  and  will  continue  to  for  as 
long  as  the  computer  runs.  Once  you 
find  the  condition  that  causes  the 
software  to  fail,  you  can  turn  your 
10-hour  MTBF  into  a  one-sec¬ 
ond  MTBF  in  a  heartbeat. 

You  don’t  want  the  system 
to  hit  that  condition  during  a 
dogfight. 

This  is  why  software  com¬ 
plexity  is  important.  You 
must  know  the  different 
software  paths  and  know 
you  have  tested  all  of  them. 
High-complexity  modules  impede  your 
ability  to  do  this,  and  unexpected  op¬ 
erational  software  failure  results.  Prop¬ 
erly  using  things  like  software  com¬ 
plexity  analysis  is  how  you  control 
software  reliability;  that  is  how  you 
manage  software  reliability.  Running 
an  MTBF  model  is  more  of  a  diversion 
than  a  help. 

Don’t  make  the  mistake  of  asking 
the  contractor  to  give  you  a  system- 
reliability  number  that  is  an  arith¬ 
metic  combination  of  hardware  and 
software  reliability  numbers  taken  from 
statistical  models.  There  is  none.  Con¬ 
ceptually,  the  two  components  are  as 
different  as  comparing  apples  and  or¬ 
anges. 

Managing  Software  Testing 

Software  testing  should  include  hu¬ 
man  testing  and  computer-based  test¬ 
ing.  For  process-immature  contrac¬ 
tors,  it  is  usually  confined  to 
computer-based  testing.  Human  test¬ 
ing  is  done  before  Unit  Test.  Com¬ 
puter-based  testing  is  Unit  Test,  Inte¬ 
gration  Test,  System  Test,  and  all 
subsequent  contractor  and  govern¬ 
ment  software  testing. 


If  you  do  good  human 
testing,  your  computer- 
based  testing  processes 
will  be  controlled, 
manageable,  and  will 
give  the  management 
flexibility  needed. 

Human  testing  is  desk  checking 
talmost  worthless);  walk-throughs  (can 
be  good,  but  you  never  know  in  ad¬ 
vance);  and,  software  inspections  (the 
best,  with  highly-consistent  and  pre¬ 
dictable  results).  Inspections,  when 
done  properly,  will  remove  a  mini¬ 
mum  of  70  percent  of  life-cycle  defects 
from  the  software  before  Unit  Test. 
Consequently,  the  traditional  com¬ 
puter-based  testing  processes,  instead 
of  being  the  primary  place  to  find  and 
fix  software  errors,  become  a  valida¬ 
tion  phase.  This  makes  your  manage¬ 
ment  job  orders-of-magnitude  easier, 
more  controlled,  and  gives  you  options 
you  would  never  have  otherwise. 


Put  human  testing  in  your  RFP  and 
contract  for  software  intensive  pro¬ 
grams.  After  Unit  Test,  the  contractor 
should  have  the  software  in  a  configu¬ 
ration-controlled  test  library,  to  which 
changes  are  made  only  with  approval 
of  the  Software  Change  Control  Board 
(SCCB),  and  made  only  by  the  Soft¬ 
ware  Control  group  (not  the  program¬ 
mers).  Remember,  Unit  Test  is  the  last 
test  phase  where  the  focus  is  inside 
the  module.  After  Unit  Test,  the  tests 
focus  primarily  on  interfaces,  between 
eSUs,  between  CSCs,  between  CSCls, 
and  between  software  and  hardware. 
It  may  be  an  informal  test,  but  its 
importance  should  never  be  underes¬ 
timated. 

Errors  detected  during  tests  using 
the  configuration-controlled  libraries 
should  be  categorized  by  severity. 
Have  the  contractor  keep  the  error- 
detection  rate  charts  for  the  total  sys¬ 
tem,  each  severity  type,  each  CSCI, 
and  each  severity  type  within  each 
CSCI.  Contractors  need  that  data  as 
much  as  you  do,  whether  they  realize 
it  or  not. 
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A  POSITIVE  FORCE 


DSMC  PAYS  TRIBUTE  TO 
DISABLED  EMPLOYEES 

“The  Defense  Systems  Management  College 
has  taught  me  to  reach  for  things 
that  were  [once]  impossible.” 


[||his  comment  by  a  Defense  Sys 
I  terns  Management  College 
I  ( DSMC )  disabled  employee  aptly 
X  describes  the  support  given  the 
government’s  Disabled  Employment 
Program  by  the  College.  Initially  hir 
ing  individuals  with  disabilities  in 
1P76,  DSMC  now  has  more  disabled 
employees  and  volunteers  than  any 
other  organization  at  Fort  Belvoir. 

A  1992  luncheon  honoring  DSMC 
disabled  employees  became  an  an 
nual  affair  with  a 
November  9,  1993, 
luncheon  for  eight 
full-time  disabled 
employees  and  five 
disabled  volunteers. 

Each  received  a 
time-in-ser\'ice  cer¬ 
tificate  and  me¬ 
mento.  Volunteers 
come  from  a  nearby 
vocational  high 
school  and  several 
local  rehabilitation 
centers  and  receive  valuable  job  and 
workplace  experience  at  the  College 

The  DSMC  provides  the  p'pe  of 
work  environment  volunteers  need  to 
obtain  resume-quality  experience.  But, 
DSMC  benefits  considerably  from  the 
performance  and  productivity  of  these 
workers,  especially  during  a  period  of 
Department  of  Defense  cutbacks  and 
downsizing. 


The  College  strongly  sup¬ 
port-'  the  Fort  Belvoir  Disabled  Em¬ 
ployment  Program.  Robert  Ball,  DSMC 
Press,  a  DSMC  disabled  employee, 
has  represented  the  College  on  the 
Fort  Belvoir  Disabled  Employment 
Program  Committee  since  1990.  Mr. 


from  top.  clockwise:  (trig 


Gen  (Scl.)  Claude  M 


iMlon.  Ir..  USAr.  DSMC 


Commandant,  and  leffrev 


Marble:  M/ehelle  M. 


McDonald:  Michael  M 


King:  Renita  K.  lane 


and  Llten  K.  Davidson. 


Ball  and  Cathy 
Pearson,  of  the 
DSMC  Civilian 
Personnel  Services 


Office,  have  re 


program. 

The  DSMC  e.xperience  with  disabled 
emplovees  and  volunteers  proves  that 
organizations  and  individuals  reap  sig¬ 
nificant  benefits  when  there  is  a  top- 
to-bottom  positix’e  attitude. 
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READINESS 


ROADMAP  FOR  MILSPEC 

REFORM 

A  National  Imperative 


ronically,  one  day  we  may  look 
back  upon  the  Cold  War  as  a 
time  of  relative  stability  and  con¬ 
tainable  risk,  a  time  when  the 
only  major  threat  to  world  peace  was 
that  the  two  superpowers  would  anni¬ 
hilate  each  other.  Today,  risks  are 
much  more  diverse  and  unpredict¬ 
able.  We  are  far  less  clear  about  who 
our  enemies  are  and  what  they  are 
capable  of  doing:  a  resurgent,  hardline 
Russia;  a  belligerent  China;  rogue 
states,  like  Iraq,  who  have  sizeable 
regional  forces;  the  unholy  nexus  of 
terrorists;  and  drug  kingpins  who  own 
the  best  in  advanced  technology  that 
billions  in  laundered  dollars  can  buy. 

At  such  a  time,  the  most  comforting 
response  would  be  to  prepare  for  all 
contingencies.  But,  the  reality  is  fi¬ 
nancial  resources  available  for  defense 
are  declining.  The  Department  of  De¬ 
fense  (DOD)  will  not  be  able  to  subsi¬ 
dize  a  defense  industrial  base  that  can 
sustain  U.S.  readiness  across-the- 
board.  It  must  take  advantage  of  exist¬ 
ing  research  and  development  (R&D), 
engineering,  and  production  capabili¬ 
ties  to  supply  defense  needs.  The  prob¬ 
lem  is  that  DOD  has  difficulty  gaining 
access  to  the  national  industrial  base. 

Two  major  barriers  stand  in  the 
way  of  integrating  civilian  and  defense 


Debra  van  Opstal  Is  a  Fellow  in 
Science  and  Technology,  Political  Mili¬ 
tary  Program,  at  the  Center  for  Strategic 
and  International  Studies,  Washing¬ 
ton,  D.C. 


Debra  van  Opstal 

production.  The  first  is  legal  and  regu¬ 
latory.  Government  contracts  often 
impose  unique  terms  and  conditions, 
requiring  information  that  commer¬ 
cial  companies  do  not  routinely  col¬ 
lect  or  cannot  certify  with  assurance. 
Companies  typically  respond  to  such 
requirements  either  by  establishing 
special  data  management  or  adminis¬ 
trative  systems  (which  add  cost  and 
inefficiency)  or  by  avoiding  certain 
typjes  of  government  contracts  alto¬ 
gether.  Because  many  of  these  require¬ 
ments  of  government  contracting  are 
rooted  in  statute.  Congress  must  act  to 
remove  these  impediments  to  a  more 
flexible  industrial  base. 

New  Report  on  MILSPECS 
Released 

A  new  Center  for  Strategic  and 
International  Studies  (CSIS)  report, 
Roadmap  forMilspec  Reform:  Integrat¬ 
ing  Commercial  and  Military  Manufac¬ 
turing,  describes  the  second  barrier  in 
detail.  The  DOD  unique  way  of  speci¬ 
fying  its  requirements,  popularly 
known  as  the  “MILSPEC”  problem, 
often  forces  companies  to  create  sepa¬ 
rate  engineering  and  production  lines 
for  defense  work  when  equivalent  ca¬ 
pabilities  exist  on  the  commercial  side 
of  the  business. 

The  need  for  some  type  of  specifi¬ 
cation  is  not  really  in  question.  All 
major  buyers  use  them  to  describe  the 
needed  item  (its  form,  fit  and  function) 
and  the  desired  level  of  performance. 
Specifications  are  needed  to  allow  the 
DOD  to  standardize  on  an  existing 


product  or  service.  They  ensure  that 
the  Department  does  not  procure  15 
different  iterations  of  the  same  part 
that  are  not  interchangeable  and  re¬ 
quire  separate  storage  and  support. 

Specifications  also  attempt  to  guar¬ 
antee  lives  are  not  lost  because  mili¬ 
tary  equipment  fails  in  the  stress  of 
combat,  a  goal  borne  of  bitter  past 
experience.  In  1879,  a  column  of  1,300 
British  soldiers  was  annihilated  be¬ 
cause  their  ammunition  cases  were 
screwed  shut.  In  1942,  the  German 
Army’s  48th  Panzer  Division  found 
that  only  42  of  the  104  tanks  en  route 
to  Stalingrad  could  be  moved;  mice 
had  eaten  the  insulation  off  the  elec¬ 
trical  wiring  of  the  other  tanks.  In  the 
South  Pacific  in  World  War  II,  U.S. 
supplies  shipped  to  the  area  at  enor¬ 
mous  expense  were  corroded  by  fun¬ 
gus.  Today,  specifications  ensure  that 
ammunition  boxes  can  be  opened 
without  tools,  insulation  is  rodent 
proof,  and  fungus  is  not  a  threat. 

The  problem,  then,  does  not  reside 
with  the  principle  of  specification. 
Rather,  the  process  by  which  specifi¬ 
cations  are  developed  and  applied  has 
become  excessively  rigid. 

Requirements  in  new  systems  are 
not  subject  to  rigorous  cost  per¬ 
formance  trade-offs  or  dual-use 
considerations.  One  cannot  de¬ 
sign  a  weapons  system  and  then 
expect  to  find  its  components 
commercially  available  or  civil¬ 
ian  factories  to  build  it. 
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The  documents  that  describe 
products  or  processes  are  flawed. 
Too  often  they  describe  com¬ 
mercial  items  in  uniquely  mili¬ 
tary  ways,  specify  obsolete  tech¬ 
nologies  or  detail  management 
practices  that  are  not  found  in 
the  commercial  sector. 

The  application  of  uniquely  mili¬ 
tary  specifications  is  largely  un¬ 
coordinated  across  the  DOD. 
MILSPECs  and  standards  are 
put  in  contracts  even  though  the 
spec  may  have  been  canceled, 
replaced  or  superseded  by  an 
updated  document. 

The  CSIS  MILSPEC  report  deals 
with  requirements,  documents  and  ap¬ 
plication  of  documents  with  specific 
recommendations  in  each  area. 

Requirements 

Military  requirements  have  either 
been  generated  by  user-pull  or 
technology-push  methods.  Often  the 
Services  will  identify  a  vulnerability 
that  cannot  be  closed  by  changes  in 
tactics  or  in  strategy;  it  must  be  met 
with  new  equipment.  At  that  point  the 
technologists  have  free  rein  to  design 
the  new  system  to  the  “wish  list”  level 
of  performance  (and  in  order  to  get 
congressional  support,  it  makes  politi¬ 
cal  sense  to  push  the  performance 
envelope  as  far  as  possible).  The  re¬ 
sult  is  usually  a  weapons  system  with 
defense-unique  features  whose  cost 
far  exceeds  real  military  value  and 
which  cannot  be  built  on  a  dual-use 
production  line. 

Despite  the  exhortation  to  use  ex¬ 
isting  product  and  process  technolo¬ 
gies  to  save  cost,  most  new  require¬ 
ments  packages  are  built  totally 
without  regard  to  whether  they  will 
require  military-unique  development 
and  production  rather  than  time-  and 
cost-effective  nondevelopment  item 
(NDI)  solutions,  particularly  commer¬ 
cial  solutions.  They  are  usually  gener¬ 
ated  without  the  benefits  of  perfor¬ 
mance  priorities  and  cost-pierformance 
trade-offs. 


In  1942,  the 
German  Army’s 
48th  Panzer 
Division  found 
that  only  42  of 
the  104  tanks 
en  route  to 
Stalingrad  could 
be  moved;  mice 
had  eaten  the 
insulation  off  the 
electrical  wiring 
of  the  other 
tanks. 


Ironically,  most  of  the  elements 
needed  to  emphasize  NDI  procure¬ 
ment  and  cost-p>erformance  trade-offs 
are  already  in  place.  The  problem  is 
they  don’t  work  well  and  often  not  at 
all.  Clearly,  what  is  needed  is  a  pro¬ 
cess  that  enforces  the  trade-offs  among 
performance,  cost  and  dual-use  op¬ 
portunities  more  aggressively.  The 
CSIS  Working  Group  on  MILSPECs 
proposed  to  formalize  specific  evalua¬ 
tion  criteria  at  Defense  Acquisition 
Board  (DAB)  milestones  one  and  two, 
in  the  review  of  Operations  Require¬ 
ments  Documents  as  well  as  in  the 
Request  for  Proposal  (RFP)  Review. 
Key  criteria  included; 

— Money.  Provide  an  up-front 
estimate  of  total  dollars  avail¬ 
able  for  the  program 


— Numbers.  Determine  how 
many  units  will  be  needed  to 
achieve  force  effectiveness 
— Priorities.  Prioritize  perfor¬ 
mance  characteristics 
— lustification.  Provide  a  solid 
rationale  for  each  requirement 
in  the  system  (a  know-why 
benchmark) 

— Market  Analysis.  Provide  a 
thorough  analysis  of  potential 
marketplace  solutions,  espe¬ 
cially  those  that  shrink  the  per¬ 
formance  envelope  to  accom¬ 
modate  lower  cost  commercial 
solutions. 

Improving  Document  Content 

The  phrase  military  specifications 
and  standards  refers  to  the  32,000 
documents  in  the  DOD  Index  of  Sp>eci- 
fications  and  Standards  (DODISS)  that 
are  uniquely  military.  The  other  1 7,000 
documents  in  the  index  are  composed 
of  other  types  of  specifications;  com¬ 
mercial  item  descriptions,  federal  stan¬ 
dards,  and  nongovernmental  stan¬ 
dards  (e.g.,  commercial  or 
international  standards). 

The  DODISS  is  such  a  mixed  bag  of 
documents,  it  is  impossible  to  arrive  at 
any  one  silver  bullet.  Some  specifica¬ 
tions  describe  products  that  are  avail¬ 
able  off-the-shelf,  such  as  white  gloves, 
tacos  or  hot  dogs.  There  is  no  real 
reason  to  have  specifications  for  such 
items.  Indeed,  they  divert  scarce  re¬ 
sources  from  the  task  of  drafting,  re¬ 
viewing  and  updating  specifications 
for  combat-related  equipment.  The 
Working  Group  recommended  that 
these  specifications  be  eliminated  or 
converted  to  Commercial  Item  De¬ 
scriptions. 

Additionally,  the  DODISS  includes 
a  number  of  specifications  —  perhaps 
as  high  as  30  percent  of  the  total 
documents  —  that  describe  obsolete 
technologies.  The  Working  Group  pro¬ 
posed  a  number  of  alternative  ways  to 
weed  out  these  specifications;  create  a 
7-year  sunset  clause  on  all  documents: 
require  coordination  with  industry 
users  in  the  overage  document  review 
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cycle;  expand  the  electronic  data  feed¬ 
back  system  to  facilitate  industry  com¬ 
ment;  and  institute  a  new  classifica¬ 
tion,  “Inactive  for  New  Design,"  for 
specifications  that  are  obsolete  but 
needed  to  maintain  active  systems. 

Complicated  Problems 

Probably  the  most  complicated 
problems  DOD  must  address  are  the 
process  and  management  specifica¬ 
tions.  These  specifications,  commonly 
called  standards,  describe  a  manage¬ 
ment  procedure  or  manufacturing  pro¬ 
cess  rather  than  a  performance  result. 
In  describing  precisely  how  the  prod¬ 
uct  is  to  be  manufactured  or  quality 
assurance  and  reliability  program  is  to 
be  structured,  or  the  work  managed, 
DOD  often  precludes  world  class  op¬ 
erations  from  applying  their  expertise 
and  technological  capability  to  de¬ 
fense  needs. 

These  process  standards  have  their 
roots  in  past  failures  —  unreadable 
instrument  displays,  substandard 
packaging,  products  that  failed  too 
soon  or  were  mismatched  to  the  larger 
system.  The  problem  today  is  that 
once  a  process  standard  is  written  and 
cited  in  a  system  design,  it  locks  in  a 
technology  for  all  future  contracts.  Be¬ 
cause  that  technology  continues  to 
evolve  in  the  commercial  sector,  the 
specification  will  eventually  be  at  odds 
with  best  commercial  practice. 

The  real  question  is  why  DOD  needs 
to  tell  contractors  how  to  perform 
manufacturing  processes  instead  of 
simply  defining  the  end  result  in  form, 
fit,  function  and  performance  terms. 
Management  standards  only 
guarantee  that  the  compliance  organi¬ 
zation  meets  the  spec,  not  that  the 
product  meets  performance  ex¬ 
pectations.  Manufacturing  standards 
cannot  keep  pace  with  state-of  the-art 
process  improvements  and  are  likely 
to  become  outmoded  even  more  rap¬ 
idly  in  a  flexible  manufacturing  envi¬ 
ronment. 

The  Working  Group  suggested  that 
DOD  can  explore  alternative  ways  to 


In  1879,  a 


column  of  1,300 
British  soldiers 
was  annihilated 
because  their 
ammunition 
cases  were 
screwed  shut. 


ensure  that  its  performance  targets  are 
met  without  imposing  process  require¬ 
ments  (e.g.,  use  third-party  certifica¬ 
tions,  acceptance  testing,  qualified 
manufacturer’s  certifications,  nongov¬ 
ernment  standards,  or  its  own  “ility” 
personnel  to  assess  whether  the 
contractor’s  system  meets  the  perfor¬ 
mance  goals). 

Noting  the  urgency  of  reform  mea¬ 
sures  in  this  area,  the  Committee  rec¬ 
ommended  that  all  high-level  or  manu¬ 
facturing  standard  should  be  converted 
to  performance-based  documents 
within  2  years.  Any  standard  that  has 
not  been  converted  within  that  period 
should  be  made  advisory  only. 

Application  of  Documents 

The  problem,  unfortunately,  is  not 
limited  to  document  content  but  in¬ 
cludes  how  the  documents  are  ap¬ 
plied.  The  buyers  of  goods  and  ser¬ 
vices  for  the  Defense  Department  do 
not  hang  their  hats  in  one  place;  they 
are  spread  out  organizationally  and 
geographically.  Although  the  docu¬ 
ments  may  be  standardized,  the  way 
they  are  referenced  in  contracts  is  not. 
That  means  that  MILSPECs  can  be 
put  on  a  contract  even  when  they  have 


been  canceled  or  replaced.  Or,  a  con¬ 
tracting  officer  might  reference  an  en¬ 
tire  MILSPEC  when  only  a  few  sec¬ 
tions  are  relevant  to  the  immediate 
purchase.  Even  worse,  that  outdated 
or  inappropriately  referenced  spec  will 
flow  down  to  all  lower-tier  suppliers. 
The  bottom  line  is  that  even  well- 
written,  performance-based  specifica¬ 
tions  can  cause  problems  if  they  are 
not  referenced  or  are  improperly  refer¬ 
enced. 

The  Working  Group  proposed  that 
DOD  should  require  program  manag¬ 
ers,  or  individuals  responsible  for  au¬ 
thorizing  purchases,  to  offer  a  ratio¬ 
nale  for  the  inclusion  of  uniquely 
military  specifications  or  standards 
before  they  are  put  on  contract.  The 
Group  recommended  that  waiver  pro¬ 
vision  be  provided  in  appropriate  cir¬ 
cumstances,  such  as,  when  the  speci¬ 
fication  has  been  certified  as  being 
performance-based  or  when  it  de¬ 
scribes  a  uniquely  military  character¬ 
istic  (e.g.,  surviving  electromagnetic 
impulses). 

Finally,  The  Working  Group  noted 
one  reason  previous  MILSPEC  reform 
efforts  failed  was  that  they  did  not 
address  the  underlying  lack  of  control 
of  the  standardization  process  by  DOD 
management. 

Lack  of  Budgetary  Control 

First,  there  is  a  lack  of  budgetary 
control.  Although  there  is  a  substan¬ 
tial  policy  hierarchy  for  standardiza¬ 
tion  activities  within  DOD  and  the 
Services,  it  has  limited  control  of  fund¬ 
ing  and  manpower  levels  of  the  offices 
(preparing  activities)  that  actually  re¬ 
view,  maintain,  convert  or  update 
specifications  in  the  DODISS. 

Standardization  is  a  corporate,  not 
a  field  command,  goal.  When  funds 
are  allocated  to  field  commands,  it 
falls  to  the  local  commander  to  allo¬ 
cate  those  resources  among  compet¬ 
ing  priorities;  for  example,  repairing 
the  facility,  maintaining  manpower 
levels,  developing  sp>ecifications  for 
new  systems,  or  sifting  through  out- 
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dated  ones  to  delete  or  modify  them. 
Not  surprisingly,  the  last  tends  to  have 
a  very  low  priority  for  the  local  com- 
manderfalbeita  high  priority  forpolicy 
makers  in  the  Office  of  the  Secretary  of 
Defense  (OSD)  who  want  to  foster 
dual-use).  There  is  no  way  to  enforce 
corporate  MILSPEC  goals  because 
there  is  no  corporate  control  of  the 
funding  or  manpower  levels  in  the 
preparing  activities. 

The  Working  Group  recommended 
that  standardization  activities  be  made 
a  line  item  in  the  budget.  Funding  for 
local  preparing  activities  should  be 
funneled  through  the  departmental 
standardization  offices  (DEPSOs)  and 
allocated  for  support  of  standardiza¬ 
tion  initiatives,  training  of  personnel, 
conversion  of  “how-to”  documents  into 
performance-based  standards  or  par¬ 
ticipation  in  internal  or  external  work¬ 
shops  on  standardization. 

Metrics  System 

Second,  DOD  management  has  no 
system  in  place  to  measure  whether 
its  policy  initiatives  are  actually  being 
carried  out.  There  are  critical  data 
elements  that  would  track  the  progress 
of  MILSPEC  reform  that  are  not  cur¬ 
rently  available,  such  as  the  volume  of 
commercial  items  being  bought  or  the 
number  of  inventory  items  (national 
stock  numbers)  bought  to  military 
specifications  as  opposed  to  some 
other  type  of  specification.  The  Work¬ 
ing  Group  strongly  recommended  that 
DOD  management  put  such  a  metric 
system  in  place. 

The  MILSPEC  reform  is  more  than 
just  a  desirable  goal.  It  is  a  national 
imperative.  Military  specifications  and 
standards  affect  most  of  the  major 
policy  issues  in  defense  procurement 
today.  They  increase  procurement 
costs  and  impede  defense  conversion 
efforts.  Unique  military  specifications 
also  hamper  DOD  access  to  the 
broader  national  industrial  base.  The 
new  administration  has  promised  to 
“reinvent  government.”  Reinventing 
the  way  DOD  does  business  offers 
one  of  the  best  places  to  start. 


DSMC  ADOPTS 
ALTERNATIVE  SCHOOL 

In  the  summer  of  1993,  the  Defense  Systems  Management  College 
(DSMC)  entered  into  the  Partners  in  Education  Program  with  the  Bryant 
Adult  Alternative  School.  Fort  Belvoir  has  seven  adopted  schools.  The 
Partners  in  Education  Program,  a  program  sponsored  by  the  Fairfax 
County,  Va..  public  school  system,  provides  the  opportunity  for  the 
working  community  at  Fort  Belvoir  to  assist  teachers  and  students  in  or 
outside  the  classroom. 

The  DSMC -adopted  students,  ranging  in  age  from  1 7-23,  dropped  out  of 
high  school  but,  since,  have  realized  the  importance  of  a  diploma  and 
pursue  its  requirements  at  the  Bryant  School. 

On  campus,  DSMC  Professor  Dan  Robinson  presented  a  workshop  on 
TQM  and  leadership  skills  in  the  classroom,  specifically  for  Bryant 
School  teachers.  Two  other  DSMC  employees  have  given  presentations 
to  Bryant  students.  Ms.  Myrna  Bass  of  the  Resource  Learning  Center 
presented  “Self  Esteem,”  and  SFC  Ivan  Blanco,  USA,  discussed  “Fitness 
vs.  Drugs  and  Alcohol  in  your  Life.” 

On  November  18, 1993, 32  students  toured  seven  different  departments 
at  DSMC.  This  tour  will  extend  into  student  “job  shadowing”  with  DSMC 
employees  at  a  later  date.  Job  shadowing  provides  a  real-life,  on-the-job 
experience  for  the  student  who  has  a  career  interest  in  a  specific  field. 

Bryant  School  supplies  DSMC  with  special  requests  for  tutors,  mentors 
and  guest  speakers.  The  DSMC  also  collects  cash-register  receipts  from 
local  grocery  stores  forclassroom  purchase  of  computers.  When  possible, 
software  is  transferred  to  the  school. 


Photo  by  Richard  Mattox 


Seated  from  left:  Brig  Gen  (Sel.)  Claude  M.  Bolton,  Jr.,  USAF,  DSMC  Commandant; 
Robert  Spillane,  Superintendent,  Fairfax  County  Schools;  and  Armand  Sebastianelli, 
Principal,  Bryant  Adult  Alternative  School;  with  student. 
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EVOLUTION  IN  C-  DEVELOPMENT 


GROUP  DECISION  SUPPORT 

SYSTEMS 

Executive  Team- Management  Tools 
For  the  Military 


The  progression  of  command 
and  control  (C-)  systems  from 
message  processors  into  execu¬ 
tive  decision  support  devices  is 
the  next  generation  of  C-  develop¬ 
ment.  This  evolution  is  being  effected 
by  user-developed  prototypes  and  by 
the  new  architecture  of  Space  and 
Electronic  Warfare  (SEW). 

In  a  spontaneous  manifestation  of 
bottoms-up  development,  tactical  de¬ 
cision  aids,  prototypes,  and  other  user- 
developed  desktop  applications  are 
coalescing  into  group  decision  support 
devices.  In  this  regard,  the  Naval  Tac¬ 
tical  Command  System-Afloat  (NTCS- 
A)  has  joined  several  prototype  de¬ 
vices  (e.g.,  JOTS,  NIPS,  POST)  into  a 
comprehensive,  LAN-based  system. 

Simultaneously,  in  a  calculated  ap¬ 
plication  of  top-down  design,  SEW 
architects  have  proposed  networks  of 
workstations  supporting  the  manage¬ 
ment  of  sensors,  information,  electro¬ 
magnetic-spectrum,  and  battle-space. 
This  architecture  mirrors  the  group 
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control  and  decision  support  technol¬ 
ogy- 
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decision-making  practices  of  the  Com¬ 
posite  Warfare  Command  (CWC).  A 
preliminary  implementation  of  this 
design  can  be  seen  in  the  Advanced 
Track  Management  System  (ATMS) 
baseline  of  the  Interim  Surveillance 
Direction  System  (SDS-I). 

In  both  cases,  command  and  con¬ 
trol  staff  members  are  being  equipped 
with  decision  support  devices  appro¬ 
priate  to  their  domains  of  expertise. 
Networking  these  processors  aggre¬ 
gates  the  work  of  the  staff  and  creates 
a  decision  support  system  for  the 
group.  Systems  of  this  type  will  dis¬ 
place  the  C-  technology  of  the  past  to 
become  the  Command  Decision  Sup¬ 
port  Systems  (CDSS)  of  the  future. 
This  article  provides  a  basis  for  under¬ 
standing  that  future. 

Background 

Business  and  academia  have  stud¬ 
ied  group  decision  making  and  Group 
Decision  Support  Systems  (GDSS)  for 
at  least  a  decade.  The  objective  of  this 
application  has  been  to  foster  consen¬ 
sus  among  ad  hoc  groups  of  indepen¬ 
dent  executives.  In  these  systems, 
mechanisms  for  information  input  and 
opinion  exchange  are  more  fully  ma¬ 
tured  than  the  mechanisms  for  alter¬ 
natives  generation  and  choice.  On  the 
other  hand,  the  development  of  group 
support  in  the  military  has  concen¬ 
trated  on  generating  and  displaying 
alternatives  to  a  seasoned  staff. 


Accordingly,  one  of  the  key  differ¬ 
ences  between  the  business  and  mili¬ 
tary  approaches  to  group  support  is 
the  client  group  itself.  The  composi¬ 
tion,  tenure  and  policies  of  the  group 
of  users  is  as  important  a  delimiter  of 
performance  as  are  the  applications 
that  are  emphasized.  While  all  groups 
of  executives  seek  to  assert  autonomy 
over  their  domains,  members  of  a  mili¬ 
tary  staff  frequently  exercise  a  virtual 
monopoly  over  their  areas  of  interest. 
Since  the  practices  and  consensus 
mechanisms  differ  for  the  two  groups, 
the  functions  of  CDSS  and  GDSS  differ. 

The  principal  services  of  GDSS  are 
the  collection  and  ranking  of  ideas 
and  the  creation  of  an  anonymous 
forum  for  discussion.  The  GDSS  build¬ 
ers  start  with  organizational  behavior 
as  an  underlying  discipline  and  ap¬ 
proach  decision  making  as  a  group 
dynamic.  The  objective  is  to  foster 
consensus  about  a  single,  multifac¬ 
eted  subject. 

The  CDSS,  on  the  other  hand,  start 
with  military  doctrine  as  their  base 
and  coordinate  tactical  decisions  con¬ 
cerning  different  areas  of  warfare  (e.g. , 
air,  surface,  subsurface)  The  group 
dynamic  of  military  leadership  typi¬ 
cally  does  not  require  that  the  deci¬ 
sions  of  a  member  of  a  command  staff 
be  negotiated.  Rather,  these  are  rec¬ 
onciled,  de  facto,  by  layering  the  re¬ 
sulting  sets  of  intersecting  directives. 
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The  result  is  a  composite  of  various 
warfare-area  decisions  which  are  pre¬ 
sented  to  the  commander  as  an  ever- 
changing  collage  of  large  screen  dis¬ 
plays. 

Because  of  this  group  behavior, 
CDSS  efforts,  to  date,  have  centered 
around  creating  decision  support  tools 
for  the  individual  staff  officers  and  on 
displaying  the  results  generated  by 
these  DSS.  The  interpersonal  and  or¬ 
ganizational  implications  for  group 
dynamics  are  yet  to  be  explored.  If 
CDSS  evolution  is  to  avoid  the  pit- 
falls'  of  the  experience,  analysis 
and  application  of  these  behavioral 
disciplines  is  required. 

The  existing,  prototype-based 
CDSS  systems  offer  ample  opportu¬ 
nity  for  beginning  these  analyses  and 
this  article  provides  its  intellectual 
basis.  It  explores  the  origins  of  deci¬ 
sion  support  technology  and  the  hier¬ 
archical  characteristics  of  decision 
making.  It  discusses  the  military  ap¬ 
plication  of  single-user  systems  as  tools 
for  alternatives  generation  and  analy¬ 
sis.  It  offers  definition  of  a  group  sup¬ 
port  system  for  the  military  (i.e.,  CDSS) 
and  offers  recommendations  for  imple¬ 
menting  behavioral  research  in  the 
development  of  CDSS. 

Evolution  of  the  Three  Types 
of  Computer-Based 
Information  Systems 

Three  broad  categories  of  Com¬ 
puter-Based  Information  Systems 
(CBIS)  have  evolved  in  response  to 
requirements  for  successively  com¬ 
plex  output.  Those  that  process  trans¬ 
actions  are  the  simplest  and  those  that 
enhance  decisions  are  the  most  com¬ 
plex  and  the  newest. 

Starting  as  sophisticated  math¬ 
ematical  tools  at  universities,  comput¬ 
ers  migrated  to  the  lowest  level  of 
business  to  support  transaction  pro¬ 
cessing.  Then,  in  response  to  the  needs 
of  midmanagement,  the  next  level  of 
CBIS  emerged  as  computers  began 
aggregating  transaction  statistics  for 
administrators.  Finally,  CBIS  are  be- 


Disdaining  straight¬ 
forward  mathematical 
applications,  the 
military  is  applying 
decision  support  to 
information  fusion  and 


to  the  subjective 
evaluation  of  tactical 


ginning  to  provide  interactive  support 
for  decision  making  at  the  executive 
level. 


The  military  use  of  computers  has 
followed  a  similar  progression  but  with 
different  application  foci.  Knowledge 
of  these  divergent  applications  can  be 
an  important  tool  for  understanding 
the  newest  CBIS  and  for  guiding  the 
future  growth  of  both.  Figure  1,  illus¬ 
trates  this  parallel  development  by 
contrasting  the  business  and  military 
applications  of  CBIS  with  the  prod¬ 
ucts  each  produces.  From  this  figure, 
it  can  be  seen  that  business  applica¬ 
tions  initially  were  straightforward  ma¬ 
nipulations  of  data  from  financial 


events  (e.g.,  payroll,  sales,  inventory). 
Likewise,  the  first  military  applica¬ 
tions  (though  delayed  several  years 
while  discreet  mathematics  was  per¬ 
fected)  were  also  dependent  on 
straightforward  mathematical  pro¬ 
cesses. 

Next,  commercial  applications  fo¬ 
cused  on  presenting  summaries  of 
transaction  data  to  midmanagement 
and  the  technology  of  Management  of 
Information  Systems  (MIS)  was  cre¬ 
ated.  The  military  applied  CBIS  tech¬ 
nology  to  message  transmission  and 
the  C^  System  emerged.  Commercial 
applications  of  MIS  moved  toward 
tools  for  simulation  and  the  military 
perfected  its  message  integration 
mechanisms. 

The  legacy  of  simulators  is  the  De¬ 
cision  Support  System  (DSS),  which 
offers  executives  the  ability  to  observe 
effects  of  ad  hoc  simulations.  Consis¬ 
tent  with  its  historical  concentration 
on  the  mathematics  of  accounting,  the 
DSS  has  been  used  as  a  financial 
planner^  in  business  for  several  years. 
The  military,  on  the  other  hand,  is 
concentrating  on  more  esoteric  appli¬ 
cations  of  decision  support.  Disdain¬ 
ing  straightforward  mathematical  ap¬ 
plications,  the  military  is  applying 
decision  supp)ortto  information  fusion 
and  to  the  subjective  evaluation  of 
tactical  alternatives. 

Although  the  field  is  just  emerging,^ 
the  DSS  is  sometimes  incorrectly  called 
a  Tactical  Decision  Aid  (TDA)  in  the 
military.  The  term  “DSS”  implies  a 
system  with  libraries  of  algorithms; 


FIGURE  1.  The  Evolution  of  Computer-Based 
Information  Systems _ 
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FIGURE  2.  The  Hierarchical  Characteristics  of 
Decision  Making 
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whereas,  TDAs  tend  to  be  unique  sin¬ 
gular  algorithms.  There  is  library  of 
TDAs  at  NADC  Pennsylvania  where 
users  can  obtain  configuration  con¬ 
trolled  programs  for  use  with  naviga¬ 
tion  problems.  Exemplified  by  the  Elec¬ 
tronic  Warfare  Commander’s  Module 
(EWCM),  military  DSSs  employ  ab¬ 
stractions  that  are  not  found  in  the 
mathematics  of  financial  DSS.  These 
methods  of  qualitative  analysis  and 
the  formulation  and  evaluation  of 
choices  offers  considerable  challenge.'' 
This  is  particularly  so  in  areas  of  orga¬ 
nizational  and  human  behavior  where 
the  process  of  decision  making  is  poorly 
understood. 

Hierarchical  Characteristics 
of  Decision  Making 

Not  surprisingly,  the  hierarchy  of 
computer-based  information  systems 
is  strikingly  similar  to  the  structure  of 
organizational  decision  making.  Fig¬ 
ure  2  projects  the  three  types  of  com¬ 
puter-based  information  systems  onto 
a  typical  military  hierarchy.  The  left 
side  shows  the  management  activity 
of  a  command  hierarchy  juxtaposed 
against  the  information  management 
tool  with  which  they  are  performed 
(right  side).  The  middle  three  columns 
illustrate:  ( 1 )  the  management  activity 
the  user  is  performing  while  applying 
his  CBIS  tools;  (2)  a  description  of  the 
data  used  by  the  CBIS;  and  (3)  the 
parameters  of  decision  making  within 
which  decisions  must  be  reached. 

As  one  ascends  the  hierarchy  of 
management  activity  and  tools,  the 
data  from  which  decisions  must  be 


made  become  less  defined  and  less 
current.  At  the  transaction  level,  (e.g., 
a  radar)  the  information  for  making  a 
decision  is  specific  and  generally  real¬ 
time.  At  the  opposite  end  of  the  hierar¬ 
chy,  upper  management  deals  with 
information  that  is  non-real-time,  has 
been  collected  from  many  sources  (i.e., 
correlated),  and  originates  at  locations 
outside  the  command.  Similarly,  the 
parameters  within  which  decisions 
must  be  made  become  less  definitive 
as  one  ascends  the  management 
hierarchy.  The  structured,  repetitive, 
optimized  decisions  the  operator 
makes  are  replaced  by  decisions  about 
unique  situations  that  the  commander 
must  make  using  unstructured  pro¬ 
cesses  (e.g.,  instinctively).  More  often 
than  not,  these  decisions  are  made 
using  a  decision  criteria  known  as 
“Satisficing.” 

This  point  is  easier  to  grasp  in  coun¬ 
terpoise  with  the  lowest  level  of  deci¬ 
sion  making:  The  bulk  of  organiza¬ 
tional  data  originates  at  the  operator 
(i.e.,  the  transaction)  level.  Here  suc¬ 
cinct,  well-defined  optimization  crite¬ 
ria,  discreet  parameters,  and  well- 
known  solution  techniques  can  usually 
be  solved  with  linear  algorithms.  Since 
this  type  of  computation  lends  itself  to 
computer  modeling,  it  is  not  surpris¬ 
ing  that  the  transaction  level  was  the 
first  to  be  automated. 

At  the  level  above  the  operator, 
where  methods  of  solving  the  problem 
are  less  structured,  decision  making 
algorithms  are  more  obscure  and  de¬ 
scriptive  modeling iscommon.  In  busi¬ 


ness,  this  type  of  midmanagement 
decision  is  often  couched  in  terms  of 
performance  differentials  (e.g. 1 0% 
above  FY  '90  consumption  levels 
for....”).  The  comparable  military  sys¬ 
tem.  the  system,  generally  does  not 
offer  such  modeling. 

As  has  been  observed,  the  origins 
of  led  these  systems  to  mature 
along  a  path  more  attuned  to  message 
processing  and  retrieval  than  to  data 
summarization.  Tracking  algorithms 
and  data  correlation  models  have  been 
built  into  latter-day  systems  such 
as  the  Flag  Data  Display  System 
(FDDS).  Military  leaders  should  learn 
to  use  these  applications  as  tools  of 
analysis  rather  than  for  the  “truth”  of 
their  output. 

At  its  most  sophisticated,  the  deci¬ 
sion  process  is  unstructured.  Its  selec¬ 
tion  criterion  are  more  attuned  to  the 
time  constraints  associated  with  mak¬ 
ing  a  choice  than  to  the  confidence  in 
those  decisions.  The  DSS  is  a  tool  for 
individual  decision  makers  and  serves 
this  type  of  choosing.  The  circum¬ 
stances  of  these  decisions  are  unique 
and  the  processes  of  selection  are  pri¬ 
marily  intuitive.  They  are  typically  the 
prerogative  of  people  who  have  con¬ 
siderable  organizational  authority  and 
autonomy  in  their  actions. 

The  hierarchical  structure  of  orga¬ 
nizational  decision  making  comple¬ 
ments  the  history  of  computer-based 
information  systems.  Likewise,  an 
appreciation  of  the  functions  of  an 
individual  DSS  presages  the  defini¬ 
tion  of  the  emerging  CDSS  application. 

DSS:  The  Single-Person 
Decision  Tool 

The  DSS,  a  device  that  supports  a 
single  decision  maker,  has  l^en  de¬ 
fined  as: 

A  man-machine  couple  that 
facilitates  the  incorporation  of 
experience  and  instinct  in  deci¬ 
sion-making.  It  allows  the  appli¬ 
cation  of  ad  hoc  simulations  as  a 
medium  for  hypothecation 
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The  utility  of  decision 
support  is  the 
stimulation  that 
successive  iterations  of 
machine-generated 
data  can  provide  to  the 
creativity  of  the  human 


(‘what  if-lng?’)  and  automated 
goal-seeking  in  the  solution  of 
complex,  non-stnjctured  prob¬ 
lems.^ 

Understanding  these  systems  re¬ 
quires  an  appreciation  of  the  intellec¬ 
tual  impetus  they  can  provide.  The 
utility  of  decision  support  is  the  stimu¬ 
lation  that  successive  iterations  of 
machine-generated  data  can  provide 
to  the  creativity  of  the  human  partner 
of  the  man-machine  couple.  In  such  a 
partnership,  the  function  of  the  ma¬ 
chine  component  is  data  recall  and  ad 
hoc  data  manipulation. 

Data  manipulation  involves  the  se¬ 
lective  use  of  applications  modules 
(e.g.,  Markov  Analysis,  Filters,  Spec¬ 
trum  Prediction)  and  the  choice  of 
models  is  the  contribution  of  the  hu¬ 
man  component.  This  choice  is  based 
on  human  insight  and  experience  and 
upon  the  opjerator’s  interpretation  of 
the  latest  iteration  of  the  data.  The 
breakthrough  that  DSS  portends  is  the 
enhancement  of  the  synergy  between 
the  optimal  capabilities  of  each  of  its 
man-machine  components.  The  use 
of  DSS  requires  enculturation,  as  the 
users  of  existing  prototype-based  sys¬ 
tems  are  beginning  to  appreciate. 

The  basic  components  of  a  generic 
DSS  are  illustrated  in  Figure  3.  This 
illustration  suggests  a  standard  set  of 
op>erational  processes  and  a  custom¬ 
ized  set  of  application  modules.  This 
design  permits  standard  man-machine 
interface  and  operations  while  provid¬ 
ing  each  warfare  specialist  with  a 
unique  set  of  applications  modules. 

Communications,  text  and  graph¬ 
ics  display,  screen  processing,  a  rule- 
based  expert  system,  model-base  man- 
agement  system,  and  database 
management  modules  should  all  be 
standard  modules.  Sets  of  applica¬ 
tions  programs  for  management  of  the 
electromagnetic  environment,  sensors 
(i.e.,  undersea,  surface  and  space), 
tracking,  information  fusion,  data  cor¬ 
relation  and  intelligence  filtering 
should  be  available  optionally. 


partner  of  the 


As  illustrated,  centralized  database 
and  model-base  facilities  host  the  com¬ 
mon  data  and  the  library  of  applica¬ 
tions  modules.  Model-base  manage¬ 
ment  facilities,*  a  new  software 
management  process  for  joining  the 
input  and  output  of  dissimilar  decision 
aids,  will  most  probably  be  required. 


sored  by  university  research,  empha¬ 
sizes  facilitation  of  the  decision  pro¬ 
cess  within  a  group.  This  work  is  slowly 
developing  a  taxonomy  of  group  deci¬ 
sion  support  but,  with  the  possible 
exception  of  Kraemer,  it  generally  ne¬ 
glects  the  military  applications.  This 
section  briefly  explores  the  emerging 
taxonomy  as  a  foundation  for  an  ini¬ 
tial  definition  of  CDSS. 

Academic  publications  generally 
treat  group  decision  support  as  follows: 

...Integrated  computer-based 
systems  which  facilitate  solution 
of  semi-  or  unstructured  prob¬ 
lems  by  a  group  that  has  joint 
responsibility  for  making  the  de¬ 
cision  (Gallupe,  1985),and...the 
application  of  information  tech¬ 
nology  to  support  the  work  of 
groups  with  a  f^ocus  on  improv¬ 
ing  group  performance  and  or¬ 
ganizational  effectiveness  (NFS 
Working  Group).  Vogel  ob¬ 
serves:  Overall,  GDSS  are  now 
recognized  as  supporting  search¬ 
ing  for  alternatives,  communi¬ 
cation,  deliberation,  planning, 
problem  solving,  negotiation, 
consensus  building,  and  vision 
sharing,  as  well  as  decision  mak¬ 
ing  for  group  members  not  in  the 
same  room  at  the  same  time.^ 


Toward  a  Definition  of 
Multi-Person  Decision 
Support  Systems 

Group  Decision  Support  System 
(GDSS)  development,  generally  spon¬ 


These  perspectives  appear  to  envi¬ 
sion  embedded  decision  aid  modules 
for  use  in  “what-ifing”  but  it  is  not 
clear  from  the  literature  that  they  do  so 


FIGURE  3,  A  Generic  Decision  Support 
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FIGURE  4.  A  Network  of  Integrated  Workstations 


to  the  same  extent  as  military  CDSS. 
Pinsonneault  and  Kraemer  offer  a  fur¬ 
ther  classiflcation.  They  differentiate 
systems  that  support  intragroup  com¬ 
munications,  Group  Communications 
Support  Systems,  from  those  that  sup¬ 
port  group  decision  making  (i.e., 
GDSS). 

It  is  their  definition  of  the  GDSS 
device  that  is  most  useful  because  it 
closely  approaches  the  salient  aspects 
of  military  applications: 

...those  systems  that  attempt  to 
structure  the  group  decision  pro¬ 
cess  in  some  way... can  support 
member’s  individual  decision 
processes  through  decision  mod¬ 
els.  This  basically  corresponds 
to  applying  Decision  Support 
Systems  (DSS)  to  groups  with¬ 
out  supporting  the  group  pro¬ 
cess  per  se.  Here  the  technology 
supports  [the]  decision  pro¬ 
cesses  of  individuals  working  in 
a  group.® 

This  is  a  more  appropriate  descrip¬ 
tion  for  the  military.  As  we  have  seen, 
the  command  structure  of  a  battle 
staff  diminishes  the  need  for  consen¬ 
sus  mechanisms.  Also,  the  decision 
aids  in  existing  applications  tend  to 
emphasize  user-machine  interaction 
and  recursive  calculation  without  re¬ 
gard  for  group  participation.  The  Tac¬ 
tical  Flag  Command  Center,  a  C^  sys¬ 


tem  that  is  being  upgraded  with  new 
tracking  and conelation  processes,  ap¬ 
pears  to  conform  to  this  definition. 

The  CDSS  prototypes  that  are  avail¬ 
able  also  appear  to  support  the  defini¬ 
tion.  Figure  4  is  based  on  the  ATMS 
model  and  shows  independent  work¬ 
stations  distributed  across  a  network 
controlled  by  database,  communica¬ 
tions  and  model-base  servers.  The 
workstations  represent  existing  proto¬ 
types  for  the  management  of  (1)  Sen¬ 
sors,  (2)  Electromagnetics,  (3)  Battle- 
space,  and  (4)  Intelligence. 

This  illustration  shows  applications 
software,  representing  tactical  deci¬ 
sion  aids  and  operational  doctrine, 
being  provided  to  the  workstations 
from  a  central  repository  (i.e.,  the 
model-base).  This  could  occur  on  an 
ad  hoc  basis  according  to  the  needs  of 
each  warfare-area  staff  member  and 
are  called  Optional  Application  Tapes 
(OATs)  in  the  “Unified-Build”  of  JOTS. 
Recognizing  that  members  of  a  Com¬ 
mand  Staff  are  experts  in  their  war¬ 
fare-areas,  some  might  prefer  to  sup¬ 
ply  their  own  personal  library  of 
applications  (e.g.,  floppy  diskettes). 
These  might  contain  the  algorithms 
and  applications  modules  that  were 
used  during  training  or  on  other  staffs. 
The  model-base  management  system 
will  accommodate  such  a  scheme.  Fi¬ 
nally,  a  large  screen  display  (i.e.,  the 
commander’s  console)  represents  the 


military  integration  medium  in  which 
the  decisions  of  the  warfare  staff  are 
reconciled. 

The  various  similarities  between 
GDSS  and  CDSS  suggest  consistency 
in  the  research  approach  to  group 
support.  However,  the  differences  be¬ 
tween  business  and  military  leader¬ 
ship  suggests  a  more  interesting  possi¬ 
bility.  As  a  comparator,  the  military 
rank  structure  and  staff  processes  (e.g. , 
“management  by  exception,”  “silence 
means  consent”)  can  offer  an  interest¬ 
ing  research  counterpoise  to  existing 
academic  research  into  consensus 
management.  This  cross-comparison 
will  accelerate  technology  transfer  be¬ 
tween  the  GDSS  and  CDSS  technical 
approaches. 

Guiding  the  Development  of 
CDSS  with  Operational 
Analysis 

Existing  CDSS  are  principally  ag¬ 
gregates  of  user-sponsored  decision 
aids  that  are  being  back-fit  into  exist¬ 
ing  command  and  control  suites.  As 
collections  of  user  developed  devices, 
the  modules  are  relatively  self-con¬ 
tained  and  provincial.  Interleaving  the 
decisions  that  are  facilitated  by  these 
tools  is  effected  (presumably)  by  the 
delimitation  of  the  warfare-areas  and 
by  the  ultimate  authority  of  the  senior 
officer. 

Accordingly,  existing  CDSS  are  si¬ 
multaneously  groupsof  individual  DSS 
workstations  and  a  single  tool  for  a 
commander.  Notwithstanding  the 
goals  of  leadership  precepts,  the  com¬ 
mander  manipulates  these  elements 
according  to  behavioral  considerations 
(among  other  things).  These  interper¬ 
sonal  mechanisms  should  be  implicit 
in  the  design  of  the  CDSS  but  they  are 
not.  Speaking  of  contemporary  sys¬ 
tems  development  efforts,  Huschheim 
observes: 

Research  into  IS  failure  has  con¬ 
cluded  that  the  primary  cause  of 
failure  is  the  lack  of  consideration 
given  to  the  social  and  behavioral 
dimension  of  IS....  A  growing  num- 
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ber  of  researchers  suggest  that 
information  systems  are  more  ap¬ 
propriately  conceived  as  social 
systems  which  rely,  to  a  greater 
and  greater  extent,  on  new  tech¬ 
nology  for  their  operation.'' 

The  spontaneous  evolution  of 
CDSS,  like  the  eruption  of  from  its 
origins  in  message  handling,  neglects 
this  important  consideration. 

These  behavioral  tactics  come  into 
play  in  various  potential  CDSS  do¬ 
mains.  One  domain  is  the  intelligence 
field  where  emphasis  on  the  integra¬ 
tion  of  intelligence  materiel  into  the 
platform  command  process  is  increas¬ 
ing.  As  CDSS  emerge  in  response  to 
the  perceived  need  for  closer  coupling 
between  the  platforms  and  informa¬ 
tion  sources  (including  sensors),  op¬ 
erational  studies  could  help  to  achieve 
oi^anizationally  workable  linkages. 

Under  the  SEW  concept,  command 
systems  are  under  consideration  that 
support  new  ASW  tactics  at  as  many 
as  three  command  echelons  (e.g.,  the 
Theatre/Region/Sector).  To  be  useful 
across  so  broad  a  management  spec¬ 
trum,  information  fusion  and  data 
correlation  requires  a  significant 
amount  of  judgmental  activity.  As  this 
implies  human  interaction  with  the 
data  as  it  matures  into  information,  it 
is  a  mandate  for  anticipating  the  effect 
of  human  behavior  upon  choosing. 
Clearly,  organizational  characteristics 
such  as  authority  and  procedures  also 
will  impact  this  process. 

Finally,  systems  have  been  built 
traditionally  from  a  full  knowledge  of 
the  practices  and  procedures  under 
which  they  will  be  employed.  At 
present,  the  operational  and  command 
relationships  of  the  new  ASW  and 
SEW  prosecution  mechanisms  are  not 
yet  established.  What  is  apparent  at 
this  time  is  that  combat  decision  sup¬ 
port  will  require  systems  that  have  a 
decentralized  architecture  of  distrib¬ 
uted,  parallel  processes  operating  in 
an  environment  of  intensely  interac¬ 
tive  command.  This  will  demand  a 


The  CDSS  that  will 
respond  to  these 
challenges  will  be 
distributed  systems 
whose  operator- 
machine  components 
process-in-parallel  and 
decide-in-concert. 


higher  level  of  interpersonal  interac¬ 
tion  among  remote  participants  than 
has  yet  been  achievedanywhere.  VVfith- 
out  a-priori  consideration  of  the  com¬ 
mand  relationships,  communications 
channels  are  likely  to  be  flooded  with 
irrelevant  coordinating  data. 

The  CDSS  that  will  respond  to  these 
challenges  will  be  distributed  systems 
whose  operator-machine  components 
process-in-parallel  and  decide-in-con- 
cert.  Spatially  distributed  teamwork 
in  manufacturing  information  is  in¬ 
creasingly  important  and  mechanically 
harder  to  achieve.  Behavioral  and  or¬ 
ganizational  considerations  are  a  ma¬ 
jor  factor  in  the  operation  of  such 
distributed  systems  and  can  be  ex¬ 
pected  to  become  a  major  aspect  of 
the  new  designs. 

A  new  Navy  laboratory,  which  is 
demonstrating  collections  of  fleet  pro- 
totypes,‘“  has  the  potential  for  investi¬ 
gating  these  new  concepts  of  informa¬ 


tion  integration.  Through  the  studies 
at  this  center,  the  definition  of  team¬ 
work  mechanisms  for  information  in¬ 
tegration  can  become  an  important 
advance  in  the  development  of  CDSS. 
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KEEP  MOVING  FORWARD 


LESSONS  LEARNED/BEST 

PRACTICES 

DAB  Milestone  Reviews 

Lt  Col  Lawrence  E.  Sweeney,  USAF 
R.  Ross  Hosse 
Kent  White 


FIGURE  1.  Three  Systems  Interconnectivity 
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Effective  Interaction 
is  Essential  for 
Program  Success 


(Figure  from  DSMC  briefing  given  by  Rich  Stillman,  Eastern  Region  Director.) 


this  article  we  share  with  the 
defense  program  management 
community  our  experiences  at 
Electronic  Systems  Center  (ESC) 
related  to  Defense  Acquisition  Board 
(DAB)  activity.  While  the  scope  of  this 
writing  is  limited  to  some  broad  issues 
and  generalities,  we  believe  this  ar¬ 
ticle  will  be  a  useful  source  of  refer¬ 
ence  for  everyone  facing  a  DAB  deci¬ 
sion  during  their  careers.  An  important 
fact  to  keep  in  mind  when  facing  a 
DAB  decision  is  —  They  Are  All  Differ¬ 
ent! 

DAB  Process  and  Milestone 
Review  Procedures 

Three  systems  that  overlap  and 
must  interact  effectively  in  order  to 
attain  success  are  the  Planning  Pro¬ 
gramming  and  Budgeting  system 
(PPBS),  the  Requirements  Generation 
System,  and  the  Acquisition  Manage¬ 
ment  System.  The  PPBS  is  subject  to 
the  Defense  Planning  Resources  Board 
(DPRB),  the  requirements  generation 
process  to  the  Joint  Requirements 
Oversight  Council  (JROC),  and  the 
DAB  governs  the  acquisition  manage¬ 
ment  process.  Key  decisions  are  based 


on  affordability,  alternatives  and  trade¬ 
offs.  Figure  1  shows  the  relationships 
of  the  three  systems. 

An  overall  understanding  of  these 
three  systems  and  their  intercon¬ 
nectivity  is  imperative  if  one  intends 
to  navigate  the  choppy  waters  associ¬ 
ated  with  a  milestone  review.  The 
primary  source  of  reference  is  Depart¬ 
ment  of  Defense  Instruction  (DODI) 
5000.2,  “Defense  Acquisition  Man¬ 
agement  Policies  and  Procedures.” 


This  Instruction  will  be  your  guide¬ 
book  for  the  following: 

— Acquisition  Process  and  Proce¬ 
dures 

— Requirements  Evolution  and  Af¬ 
fordability 

— Acquisition  Planning  and  Risk 
Management 

— Engineering  and  Manufacturing 

— Logistics  and  Other  Infrastruc¬ 
ture 

— Test  and  Evaluation 

— Configuration  and  Data  Manage¬ 
ment 

— Business  Management  and  Con¬ 
tracts 

— Program  Control  and  Review 

— Special  Situations 

— Defense  Acquisition  Board  Pro¬ 
cess. 


Lt  Col  Sweeney  has  participated  in  five  DABs  and  was  the  Deputy  Program 
Director  for  Business  Management  for  the  Space  and  Missile  Warning  Program 
Office  at  Electronic  Systems  Center  (ESC),  Hanscom  AFB,  Mass.  Mr.  Hosse  was 
the  DAB  coordinator  reporting  to  Lt  Col  Sweeney  for  the  Cheyenne  Mountain 
Upgrade  (CMU)  Program  under  the  Space  and  Missile  Warning  Program  Office 
at  ESC.  Mr.  White  headed  the  support  contractor  team  from  CTA  Inc.,  for  both 
the  1989  and  1992  CMU  DABs. 
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You  should  become  intimately  fa¬ 
miliar  with  the  last  item  on  this  list  as 
soon  as  possible  if  there  is  a  remote 
chance  you  will  face  a  milestone  re¬ 
view.  Figure  2  lays  out  a  generic  flow 
for  typical  milestone  reviews  and  can 
be  used  as  a  rule  of  thumb.  The  Office 
of  the  Secretary  of  Defense  (OSD)  and 
Air  Force  reviews  (see  acquisition  re¬ 
view  process)  are  listed  separately  in 
order  for  you  to  view  the  two  distinc¬ 
tively,  realizing  both  will  be  prepared 
for  concurrently.  We  have  used  the 
Air  Force  Review  Process  here  as  an 
example  because  of  our  familiarity 
with  the  process;  however,  we  are  con¬ 
fident  you  can  substitute  other  respec¬ 
tive  Service  review  processes  for  the 
Air  Force  approach  with  little  difficulty. 

Lessons  Learned 

The  lessons  learned  are  related  di¬ 
rectly  to  the  formal  service  and  DOD 
reviews  along  with  the  documentation 
required.  The  first  step  is  to  review 
thoroughly  the  processes  and  proce¬ 
dures  necessary  to  allow  for  a  DAB 
decision.  The  “Defense  Acquisition 
Board  Process”  is  found  in  DODI 
5000.2;  Part  13  and  “Milestone  Re¬ 
view  Procedures  and  Documentation” 
are  located  in  DODI  5000.2,  Part  1 1, 
Section  C.  In  addition  to  the  familiar¬ 
ization  with  these  areas  of  the  DODIs, 
we  found  it  absolutely  necessary  to 
review  all  prior  DAB  assessments,  re¬ 
ports,  action  items,  etc.,  related  to  our 
programs.  For  example,  we  reviewed 
prior  Cost  Analysis  Improvement 


Group  (CAIG)  reports.  Air  Force  Sys¬ 
tems  Acquisition  Review  Council 
(AFSARC)  Implementors,  Program  As¬ 
sessments,  Documentation  Memos, 
Acquisition  Decision  Memos  (ADMs), 
Test  and  Evaluation  (T8fE)  Reports, 
Planning  MeetingMemos,  and  Acqui¬ 
sition  Strategy  documents. 

Major  Issues  Guidance 
Document 

This  document  should  be  published 
by  OSD  seven  days  following  the  plan¬ 
ning  meeting.  The  Draft  Integrated 
Program  Summary  (IPS),  the  primary 
decision  document  for  the  DAB,  will 
be  published  about  105  days  after  the 
Major  Issues  Guidance  Document  is 
released.  This  document  identifies  is¬ 
sues  pertaining  to  exit  criteria  and 
establishes  minimum  program  accom¬ 
plishments  for  presentation  to  the 
DAB. 

Lessons  Leamed/Best 
Practices 

— Focus  on  producing  a  draft  of  the 
IPS  as  quickly  as  possible  after  the 
planning  meeting.  Coordinate  in  par¬ 


allel  and  work  any  issues  and  any 
changes  in  real  time.  This  will  take 
some  effort  but  if  you  stay  a  step 
ahead  and  coordinate  your  approach 
prior  to  the  program  review  meetings, 
things  will  go  more  smoothly  than  you 
think. 

— Seek  consensus  on  issues  before 
guidance  is  released.  Make  some  calls, 
send  some  faxes,  and  ensure  you  have 
Service  and  user  agreements,  in 
principle,  on  the  issues.  If  the  user  will 
not  support  your  jx)sition,  you  have  a 
problem. 

— The  Major  Issues  Guidance 
Document  becomes  a  benchmark  for 
all  subsequent  reviews  in  the  milestone 
review.  Deal  with  the  major  issues 
early  because  you’ll  find  even  if  the 
issue  goes  away,  the  questions  won’t. 

Draft  Documentation 
Submission 

This  documentation  is  not  yet  ap¬ 
proved  by  the  Milestone  Decision  Au¬ 
thority,  but  is  approved  by  the  Service. 
From  a  program  manager’s  perspec- 


FIGURE  2.  Generic  DAB  Flow  (Typical  Milestone  Reviews). 
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tive,  this  is  the  final  draft.  All  docu¬ 
mentation  must  be  approved  by  the 
Service  and  copies  are  provided  to  the 
OSD  action  officer.  The  due  date  is  45 
days  before  the  respective  committee 
review  and  the  review  date  will  slip 
if  the  documents  don’t  come  in  on 
time. 

Lessons  Learned/Best 
Practices 

— Ensure  proper  lead  time  for  Ser¬ 
vice  coordination.  Run  a  Program 
Evaluation  Review  Technique  (PERT) 
analysis  with  an  optimistic,  pessimis¬ 
tic  and  modal  time.  The  time  it  will 
take  will  most  likely  fall  somewhere 


FIGURE  3.  D(Kument  After  Planning  Meeting 


7  Days , 


105  Days 


— Where  possible,  precoordinate 
with  OSD  staff  offices  months  in  ad¬ 
vance  to  ensure  the  approach  and 
content  are  satisfactory  at  least  in  prin¬ 
ciple.  It  is  understood  that  your  Ser¬ 
vice  may  be  hesitant  to  release  a  less 
than  fully  coordinated  Service  posi- 


Lessons  Leamed/Best 
Practices 

— The  entire  review  cycle  is  a 
lengthy  process,  so  start  early.  Nu¬ 
merous  agencies  must  coordinate  and 
this  can  take  feasibly  9-12  months  to 
complete. 


—Work  closely  with  AF,  OSD  and 
AFOTEC  staff  offices  throughout  the 
process. 

— Seek  consensus  and  work  to  re¬ 
solve  issues  early.  As  soon  as  issues 
arise,  get  on  the  phone,  write  point 
papers,  orsend  correspondence.  Com¬ 
municate  well  and  try  to  reduce  the 
possibility  of  issues  getting  out  of  hand: 
keep  them  solvable. 


in-between  the  two  extremes.  Allevi¬ 
ate  undue  stress  and  simply  do  a  little 
up-front  planning. 

— Provide  a  program  acronym  list¬ 
ing.  Thiscourtesy  will  pay  dividends. 
All  of  us  have  our  Service,  command 
and  program  specific  language.  Make 
it  easy  on  the  reader  and  things  will 
probably  be  easier  for  you. 

— Establish  configuration  control 
procedures  and  keep  an  audit  trail  of 
all  changes  to  the  documents.  Devise 
a  documentation  matrix  to  cross-check 
information  consistency.  Things  can 
get  hectic  but  without  proper  change 
controls,  you’ve  got  chaos.  For  ex¬ 
ample,  someone’s  opinion  may  slip  in 
that  it  contradicts  the  program 
director’s  recently  coordinated  posi¬ 
tion.  It’s  easier  to  change  it  back  than 
to  search  for  the  guilty  party.  Also, 
with  a  matrix,  you  can  ensure  changes 
are  made  that  apply  to  more  than  one 
document. 


tlon;  however,  discuss  the  informa¬ 
tion  that  is  common  knowledge  and 
see  if  you  can  reach  early  agreements 
on  the  format  and  approach  to  pre¬ 
vent  unnecessary  rework.  In  other 
words,  don’t  try  to  outguess  OSD;  ask 
the  questions.  More  often  than  not, 
you’ll  get  good  answers. 

—Make  sure  the  documentation 
answers  the  Major  Issues  Guidance. 
This  may  sound  overly  simplistic,  but 
be  absolutely  sure  you’ve  answered 
the  mail. 

Test  and  Evaluation  Review 

The  Test  and  Evaluation  Master 
Plan  (TEMP)  is  reviewed  with  the  DOD 
director  of  operational  testing  and  the 
DDR&E  director  of  developmental 
testing.  This  plan  lists  critical  test 
objectives  and  outlines  the  test  ap¬ 
proach  and  methodologies.  The  re¬ 
view  objective,  from  a  program 
manager’s  viewpoint,  is  to  obtain 
TEMP  approval. 


—A  “red-line”  session  as  soon  as 
possible  is  suggested  for  the  draft 
TEMP,  with  as  many  coordination 
agencies.  Face-to-face  communica¬ 
tion  can  head  off  or  resolve  issues 
quickly. 

Documentation  Review 

This  review  takes  place  two  weeks 
after  draft  documentation  submission 
and  is  chaired  by  the  OSD  oversight 
office  (OSD  action  officer).  Represen¬ 
tatives  for  all  OSD  committee  prin¬ 
ciples  and  DOD  components  attend. 
Major  questions  or  issues  raised  by 
the  documentation  are  identified  and 
reviewed,  and  new  program  develop¬ 
ments  are  focused  on.  The  final  result 
is  a  documentation  review  memo  to 
the  Service  acquisition  executive. 

Lessons  Leamed/Best 
Practices 

— ^This  review  is  an  ideal  opportu¬ 
nity  to  focus  an  issue  resolution.  Close 
as  many  issues  as  possible. 
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—Communication  is  key.  Seek  a 
clear  understanding  of  comments  re¬ 
ceived,  which  should  be  provided  in 
writing. 

—The  user  rather  than  the  system 
program  director  should  brief  require¬ 
ments. 

—Help  OSD  d-aft  the  documenta¬ 
tion  review  memo  by  recapping  the 
issues  and  categorizi  ng  them  into  three 
areas  —  major  issues,  minor  issues 
and  documentation  comments. 

Committee  Review 

This  review  ensures  exit  criteria  are 
met  and  program  accomplishments 
are  completed.  The  committee  re¬ 
views  all  issues  and  provides  an  Inte¬ 
grated  Program  Assessment  to  the  DAB 
Principles.  The  committee  also  pro¬ 
vides  a  “read-ahead"  (one-page  issue 
summaries  of  all  documents)  and  rec¬ 
ommends  issues  to  the  DAB.  This  is 
the  most  critical  of  all  pre-DAB  re¬ 
views  and  occurs  approximately  14 
days  prior  to  the  DAB. 

Lessons  Learned/Best 
Practices 

—The  program  manager  usually 
briefs  the  Integrated  Progra’"  Sum¬ 
mary  and  actions  to  resolve  major 
issues.  From  the  time  the  draft  docu¬ 
ments  are  submitted,  all  discussions 
should  focus  on  resolving  major  is¬ 
sues.  Issue  resolution  should  address 
cost,  schedule  and  performance  pa¬ 
rameters,  incli'.diiig  risk-management 
decisions  and  affordability  trade-offs. 

— ^The  committee’s  purpose  is  to 
make  recommendations  concerning 
the  merits  of  proceeding  with  the  pro¬ 
gram  and  the  exit  criteria  for  the  next 


review.  If  the  process  is  working  cor¬ 
rectly,  the  recommendations  here 
should  come  as  no  surprise. 

A  Few  Words  of  Advice  from 
Our  DAB  Experiences 

— ^As  your  team  progresses  through 
the  process,  focus  on  remaining  road¬ 
blocks  so  progress  is  continuous.  Make 
sure  you  keep  moving  forward. 

— Provide  your  DAB  coordinator 
with  authority  and  make  it  clear  to  the 
troops  that  the  DAB  is  a  highly  impor¬ 
tant  exercise  and  everyone’s  help  is 
required  —  move  it  to  the  top  of  the 
program  office  priorities. 

— Keep  everyone  informed  and 
quickly  coordinate  fast-breaking  news. 

— Build  a  “can  do"  attitude  in  your 
team.  The  DAB  process  is  no  easy 
task  and  you  won’t  be  able  to  promise 
a  painless  process,  but  you  can  moti¬ 
vate  people  and  reward  the  small  and 
more  grand  accomplishments.  Re¬ 
member,  the  DAB  is  a  1-2  hour  brief¬ 
ing  that  is  really  a  culmination  of  many 
smaller  accomplishments. 

—Use  experts  whenever  possible. 
You’ll  save  time  and  effort  if  you  have 
the  expert  with  you  to  head  off  ques¬ 
tions  and  clarify  issues. 

— Be  as  proactive  as  possible  and 
ask  for  advice.  Seek  out  people  who 
have  been  through  the  process,  see 
your  DSMC  regional  director,  and  call 
anyone  you  think  can  offer  help. 

— Finally,  keep  an  open  mind,  a 
good  sense  of  humor,  stay  flexible, 
and  take  your  vitamins  —  you’re  go¬ 
ing  to  need  the  enei^. 


DSMC  JOINS 
THE  INTERNET 


The  Defense  Systems  Management 
College  is  in  the  midst  of  a  major 
program  to  upgrade  the  automation 
facilities  for  staff,  faculty  and  students. 
Named  the  Electronic  Campus  Project, 
the  future  systems  at  DSMC  will  im¬ 
prove  the  College  computing  capabili¬ 
ties  and  will  allow  students  to  main¬ 
tain  contact  with  the  faculty  after 
graduation.  Classroomswill  have  new 
computers  with  CD-ROM  players, 
campus  network  access,  and  the  lat¬ 
est  office  automation  software.  The 
DSMC  library  will  have  a  new  system 
with  improved  cataloging  and  on-line 
access  to  information  services.  When 
the  Electronic  Campus  is  completed, 
a  fiber  optic  backbone  network  will 
interconnect  automation  assets 
throughout  the  campus. 

In  January  1994,  the  DSMC  Elec¬ 
tronic  Campus  e-riail  system  was  in¬ 
tegrated  initially  into  the  MILNET  and 
the  Internet.  As  the  Electronic  Cam¬ 
pus  grows  during  1994,  eventually 
everyone  on  campus  will  have  world¬ 
wide  access  via  e-mail.  When  the 
Electronic  Campus  Project  is  com¬ 
pleted,  full  Internet  services,  includ¬ 
ing  TELNET  and  FTP,  will  be  avail¬ 
able.  Additionally,  a  bulletin  board 
system,  open  for  public  use  and  fo¬ 
cused  on  acquisition  and  program 
management  information,  will  be  in¬ 
stalled. 

The  Internet  e-mail  addresses 
at  DSMC  are  of  the  form 
username@dsmc.dsm.mil,  where 
username  is  normally  a  person’s  last 
name  and  first  initial.  All  DSMC  staff 
and  faculty  will  be  registered  in  the 
MILNET,  0  savvy  users  can  use  the 
WHOIS  service  on  MILNET  to  look 
up  names  and  e-mail  addresses.  The 
DSMC  host  computer  is  a  Sun 
Microsystems  Model  4-370,  and  the 
IP  address  is  198.97.207.254. 

For  assistance  with  the  DSMC  Elec¬ 
tronic  Campus,  contact  LTC  Bert 
Garcia,  USA,  (703)  805-3462,  or  via  e- 
mail  at  garciab@dsmc.dsm.mil. 


FIGURE  4.  Draft  Documentation 
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GLIDING  INTO  HISTORY 


TWO  PROPELLERS 
SHORT  OF  A  PLANE 


The  American  Introduction  of  Gliders 
Into  Combat  in  Sicily,  1 943 


I  cquisition  professionals  have  much 
■  to  gain  from  studying  the  past. 

II  We  are  busy  with  programs  val- 
li  ued  at  millions  or  billions  of  dol¬ 
lars  and  are  concerned  about  execut¬ 
ing  them  successfully.  Defense  acqui¬ 
sition  has  played  an  important  role  in 
20th  Century  American  history. 

The  most  dramatic  transformations 
in  the  American  political  economy 
have  occurred  during  wars.  The  mili¬ 
tary  plays  a  significant  role  in  mobiliz¬ 
ing  the  nation’s  resources  for  war  and. 
in  the  cases  of  the  two  world  wars,  no 
sector  of  the  economy  escaped  gov¬ 
ernment  interference. 

As  we  fulfill  our  responsibilities  in 
peacetime,  we  should  understand  the 
actual  and  potential  consequences  of 
our  actions.  Studying  myriad  ways  the 
government  and,  more  specifically  the 
military,  injected  itself  into  the  Ameri¬ 
can  economy  is  a  daunting  task,  espe¬ 
cially  if  one  considers  America  in  the 
1900s.  My  goal  is  more  limited.  This 
article  provides  an  example  of  the 
importance  of  ideas  in  military  and 
economic  affairs  by  using  a  case  study 
from  World  War  II  (WW II). 


Captain  Jones  is  assigned  to  the 
Department  of  History,  U.S.  Air  Force 
Academy.  Research  for  this  article  was 
supported  in  part  by  a  grant  from  the 
DSMC/USAF  Academy  Joint  Research 
Group. 


Captain  Hadd  Jones,  USAF 

1941-1945 

Technological  innovation  lies  at  the 
heart  of  defense  acquisition ,  and  ideas 
and  beliefs  about  the  nature  of  war¬ 
fare  properly  influence  acquisition  de¬ 
cisions.  The  development  and  use  of 
military  gliders  between  1941  and 
1945  illustrate  this  point. 

From  their  first  use  in  combat  dur¬ 
ing  the  invasion  of  Sicily  in  July  1943 
to  the  end  of  the  war,  gliders  promised 
much  but  delivered  little.  An  analysis 
of  their  implementation  underscores 
interaction  between  the  home  front 


The  Northwestern  XPC-2A.  a  CC-4  with  engines. 


Photos  from  Special  Collections  Branch,  USAF  Academy  Library. 
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and  battle  front,  the  military  and  in¬ 
dustry.'  It  focuses  on  the  process  of 
technological  innovation  and  the  key 
role  ideology  plays  in  the  process.  As 
a  military  weapon,  the  glider  failed  in 
WW II  largely  because  American  air¬ 
men  adhered  to  a  strategic  bombing 
doctrine  for  which  the  glider  played  no 
major  role. 

Innovation/Ideology 

At  this  point,  innovation  and 
ideology  deserve  explanation.  A  defi¬ 
nition  of  innovation  can  be  straight¬ 
forward;  in  the  simplest  terms,  it  is 
anything  new  to  an  organization. 

The  CG-4  glider,  nicknamed  “Hadrian,  ’’  carried  15  fully  equipped  sol¬ 
diers  and  a  small  jeep,  accessible  through  the  nose  section  of  the  plane. 


(AAF)  had  not  considered  them  seri¬ 
ously  until  1940.  But  shortly  thereaf¬ 
ter,  many  organizations  within  the  U.S. 
Army  began  simultaneous  efforts  to 
employ  the  military  glider  technology. 


Prevailing  ideology  powerfully  in¬ 
fluences  the  hundreds  of  decisions  the 
innovation  process  demands.  An  ide¬ 
ology  orients  an  organization  with  re¬ 
spect  to  its  past  and  its  vision  of  the 
future.^  This  shared  definition  of  the 
organization  and  what  it  will  be  guides 
decision  making  and  is  reflected  in 
planning  and  execution  of  plans.  It 
has  obvious  implications  for  innova¬ 
tion,  as  the  Ameri¬ 
can  introduction  of 
gliders  into  combat 
in  Sicily  clearly  re¬ 
veals. 


The  main  actors 
in  this  story  of  tech¬ 
nological  innova¬ 
tion  were  the  Army 
Air  Corps,  renamed 
the  AAF  on  June  20, 
1941,  and  the  Waco 
Aircraft  Company 
of  Troy,  Ohio.  Both 
had  visions  of  the 
future  which  grew 
from  their  interwar 
experiences,  and 
both  had  set  plans 
reflecting  these  pre¬ 
sumptions. 


It  does  not  have 
to  be  something 
original  outside  the 
organization  — 
brand-new  cre¬ 
ations  are  not 
necessary  for  inno¬ 
vation  to  occur.^ 

This  is  an  impor¬ 
tant  point.  Military 
gliders  existed  in 
the  German  and 
British  air  forces  by 
1939.  The  U.S. 
Army  Air  Forces 


For  the  AAF,  stra¬ 
tegic  bombing  doctrine  served  as  an 
ideology  and  shaped  airmen’s  notions 
of  innovation.  Likewise,  Company 
President  Clayton  J.  Brukner  commu¬ 
nicated  his  vision  for  the  future  and 
developed  plans  to  ensure  viability  of 
his  company.  These  plans  set  Waco 
on  a  path  intersecting  the  AAF  road 
toward  mobilization  —  and  indepen¬ 
dence. 

The  Ultimate  Weapon 

The  AAF  entered  the  industrial  mo¬ 
bilization  game  late,  despite  the  fact 
that  aviation  had  captured  the  imagi¬ 
nation  of  some  Army  officers  and  the 


American  public  during  World  War  I 
(WW  1).  In  the  minds  of  some,  after 
the  war  the  expectation  grew  that 
planes  could  serve  as  the  ultimate 
weapon.  As  a  result  of  theoretical 
studies  at  Maxwell  Field,  Ala.,  airmen 
ultimately  claimed  that  high  altitude, 
daylight  and  precision  bombing  of  an 
enemy’s  economic  infrastructure 
would  single-handedly  win  future 
wars.^ 

As  air  leaders  of  this  opinion  domi¬ 
nated  the  AAF ,  they  were  able  to  direct 
the  little  money  received  during  the 
depression  toward  their  vision.  Con¬ 
tinued  technological  advances  fueled 
the  public’s  and  airmen’s  enthusiasm 
for  air  power.  For  some,  this  promised 
an  alternative  to  the  holocaust  of  WW 
I.^  In  order  to  turn  these  visions  into 
reality,  airmen  pursued  aeronautical 
innovations  which  supported  their 
evolving  conception  of  war.  The  best 
example  of  this  ideologically  focused 
research  was  the  Boeing  B-17  heavy 
bomber. 

According  to  its  most  ardent  sup¬ 
porters,  the  B-17  had  the  range  and 
payload  which  would,  with  sufficient 
numbers,  bring  an  enemy  to  its  knees 
quickly.  With  doctrinal  and  techno¬ 
logical  issues  settled,  airmen  addressed 
the  neglected  problem  of  industrial 
mobilization. 

The  Strategic  Bombing  Doctrine 

As  war  approached  in  the  after- 
math  of  the  September  1938  Munich 
Crisis,  the  biggest  problem  was  to  ac¬ 
quire  enough  B-17s  and  other  heavy 
bombers  to  implement  the  strategic 
bombing  doctrine.  This  would  take  all 
the  manufacturing  capability  of  the 
major  aircraft  companies  and  leave 
them  unable  to  produce  anythingelse. 
General  Henry  H.  “Hap”  Arnold,  Com¬ 
manding  General  of  the  AAF,  knew  he 
had  to  find  more  manufacturing  ca¬ 
pacity.  He  pointed  out: 

...some  of  the  airplane  compa¬ 
nies  such  as  Waco,  Ryan, 

Stinson,  Beech  Aircraft  Corpo¬ 
ration,  Spartan  and  possibly  oth- 
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Recommended  changes  in  the  CG-4  resulted  in  the  XCG-I5  in  1944,  with  a  wingspan  21  feet 
less  than  the  CG-4A.  It  could  land  on  a  shorter  runway. 


ers  who  are  nowj5uilding  com¬ 
mercial  airplanes  have  had  suf¬ 
ficient  airplane  manufacturing 
experience  to  t^.  alify  them  for 
the  manufacture,  in  time  of  emer¬ 
gency,  of  the  primary  training 
and  basic  training  types.. ..If  the 
burden  on  the  peace  time  mili¬ 
tary  airplane  industry  can  be 
lightened  in  this  manner,  in¬ 
creased  experienced  capacity 
will  be  available  for  the  emer¬ 
gency  requirements  in  military 
combat  types.® 

Only  two  months  previously, 
Bruknervolunteered  Waco  for  defense 
contracting  and  now  was  waiting  for 
the  orders  to  arrive.^  Not  surprisingly, 
Colonel  A.  W.  Robins’  more  detailed 
planning  premises  included  elements 
of  this  guidance.  For  example,  first  on 
his  list  of  priorities  was  “[ajssigning 
Army  types  and  models  to  respective 
current  manufacturers.”®  By  the  sum¬ 
mer  of  1 94 1 ,  defense  contractors  were 
approaching  capacity,  and  Waco’s 
turn  was  near.  When  the  company 
won  its  laigest  defense  contract,  the 
result  was  the  birth  of  the  military 
glider  program. 

Glider  Program 

Arnold’s  decision  to  initiate  the 
glider  program  derived  from  develop¬ 
ments  overseas.  The  Soviet  Union  and 
Germany  had  experimented  with  glid¬ 
ers  before  the  outbreak  of  war  in  1 939. 
American  airmen  knew  this  but 
showed  no  interest  in  this  unique  aero¬ 
nautical  capability.’  In  some  measure, 
this  was  due  to  their  focus  on  strategic 
bombing.  Gliders,  after  all,  were  a 
tactical  weapon  and  had  ties  to  the 
Army.  Such  an  auxiliary  use  of  air 
power  detracted  from  the  strategic 
mission  airmen  were  trying  to  accom¬ 
plish.  Auxiliary  aviation  had  found  a 
more  receptive  audience  in  the  Ger¬ 
man  military. 

The  Luftwaffe  embraced  the  idea  of 
marrying  air  power  with  ground  forces 
and  put  the  glider  to  effective  use  in 
the  Low  Countries  in  1940  and  Crete 
in  1941.  Arnold  knew  the  American 


air  force  had  no  similar  capability. 
Despite  the  glider’s  doctrinal  incon¬ 
gruity  in  the  AAF,  he  ordered  Wright 
Field  to  introduce  the  innovation  as 
soon  as  possible.  With  such  high  pri¬ 
ority  and  little  guidance,  the  AAF 
struggled  to  define  what  a  military 
glider  actually  was.  The  plans  to 
achieve  the  general’s  goals  were  un¬ 
derstandably  confused. 

Thus,  the  sudden  emergence  of  the 
glider  program  in  June  1941  required 
drastic  actions.  The  need  for  a  new 
kind  of  pilot  meant  that  the  Secretary 
of  War  had  to  countermand  a  1932 
order  prohibiting  Army  personnel  from 
flying  in  a  glider.'®  Since  peacetime 
military  contractors  were  fully  engaged 
in  mobilization,  procurement  officials 
had  to  establish  relationships  with 
companies  about  which  they  knew 
little.  But,  the  heightened  importance 
of  gliders  could  not  shake  the  priori¬ 
ties  airmen  had  established  through 
the  years,  nor  did  it  overturn  existing 
plans. 

Constraints  on  Program 

These  new  ties  with  business,  for 
example,  were  to  conform  to  the  AAF 
scheme  for  mobilization.  Constraints 
on  the  glider  program  included  no 
interference  with  ongoing  military  con¬ 


tracts,  designs  which  minimized  or 
avoided  the  use  of  any  materials  also 
employed  in  the  strategic  bomber  pro¬ 
gram,  anda  much  lower  priority  rating 
for  materials  that  met  a  need  else¬ 
where  in  the  mobilization  program." 
Less  than  12  months  after  develop¬ 
ment  started,  these  conditions  jeopar¬ 
dized  Arnold’s  desire  to  field  gliders 
quickly. 

As  a  result,  the  program  got  off  to  a 
rough  start.  Intelligence  from  Europe 
indicated  that  the  German  glider  could 
carry  1 5  equipped  soldiers  and  a  small 
truck.  Wright  Field  officials  used  this 
to  guide  the  companies  that  offered 
specific  proposals  to  the  military  for 
the  glider.  With  no  American  experi¬ 
ence  from  which  to  draw,  the  German 
information,  though  sketchy,  was  a 
start. 

Attempts  to  have  Soviet  documents 
translated  into  English  offered  early 
evidence  that  the  glider  problem  would 
be  tough  to  solve.  Intelligence  ana¬ 
lysts  told  Wright  Field  that  the  Rus¬ 
sian  translators  were  too  busy  with 
higher-priority  projects.'^  The  techni¬ 
cal  requirements  for  the  American 
military  glider  evolved  slowly  as  the 
senior  leadership  struggled  to  deter¬ 
mine  its  combat  role. 
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Sixteen  Contractors 

Initially,  the  Air  Force  chose  16 
contractors  to  manufacture  CG-4  glid¬ 
ers.  Waco  produced  the  design  and 
was  primary  engineering  con¬ 
tractor, and  also  a  major  manufacturer 
of  the  glider.  If  Waco  had  been  in  the 
second  tier  of  companies  the  AAF  con¬ 
sidered  during  mobilization ,  then  these 
companies  Waco  worked  with  were 
even  further  outside  parameters  the 
AAF  set  for  consideration. 

Included  in  this  group  were  new¬ 
comers  to  the  aviation  business  like 
the  Babcock  Aircraft  and  Robertson 
Aircraft  companies.  Another  new  ar¬ 
rival  was  Ford,  as  it  converted  its  vast 
production  facilities  to  the  avi.ition 
program.  Included  were  more  recog¬ 
nizable  aviation  names,  most  notably 
the  Cessna  Company.  Engaged  in  other 
aspects  of  mobilization,  Cessna  was 
tagged  by  AAF  as  one  of  the  most 
competent  companies  in  the  glider 
program.  But  Waco  had  to  deal  with 
other  firms  new  to  mass  production 
and  defense  contracting,  the  most 
outstanding  example  being  the  Ward 
Furniture  Company.  Many  of  these 
disparate  producers  asked  for,  and 
were  usually  granted.  Army  permis¬ 
sion  to  deviate  from  the  master  design 
when  compliance  meant  a  longer  de¬ 
livery  schedule.'^  Brukner  faced  a  dif¬ 
ficult  task  in  coordinating  this  diverse 
collection  of  producers,  and  drew 
empathy  of  officials  at  Wright  Field. 
One  wrote,  “Poor  old  Waco  doesn’t  do 
anything  else  but  interview  firemen 
who  want  to  build  gliders.”'" 

The  CG-4  Glider 

The  CG-4  glider,  nicknamed  the 
“Hadrian,”  saw  the  most  combat  ac¬ 
tion  during  the  war.  The  nose  section 
opened  vertically  upward  (similar  to 
today’s  C-5  aircraft),  thus  allowing 
rapid  on-  and  off-loading  of  men  and 
equipment — if  the  glider  landed  intact. 

Through  a  series  of  experiments, 
the  AAF  determined  that  the  Douglas 
C-47  cargo  plane  made  the  best  tug, 
towing  up  to  three  gliders  simulta¬ 
neously.  During  the  war,  other  cargo 


aircraft,  bombers  and  even  fighters 
towed  gliders  on  occasion:  but,  the 
C-47S  did  the  bulk  of  the  work.  The 
CG-4  won  no  contests  for  beauty  or 
gracefulness,  but  it  could  carry  15 
fully-equipped  soldiers  and  a  light  jeep, 
a  significant  load  of  combat  power. 

Further  complicating  the  difficult 
manufacturing  program  was  the  AAF’s 
continuing  ambivalence.  The  only  con¬ 
stant  in  the  program  was  its  urgency. 
Commanders  debated  concerning 
types  and  quantities  of  aircraft;  they 
tinkered  with  the  pilot  training  pro¬ 
gram  to  the  extent  that,  even  when 
gliders  were  ready  for  the  front,  the 
AAF  had  no  pilots  to  fly  them. 

Difficult 

Innovation 

Typical  of  these  dealings  was  a 
February  1942  meeting  among  offic¬ 
ers  from  Army  organizations  with  a 
stake  in  the  glider  program.  The  per¬ 
son  from  headquarters  in  Washington 
said  designs  were  too  costly  and  bulky 
— gliders  should  take  up  less  room  on 
the  transport  ships  than  presently 
planned.  Moreover,  he  added  that 
Arnold  wanted  gliders  which  withstood 
only  one  use:  the  aircraft  should  es¬ 
sentially  be  disposable. 

The  Wright  Field  representatives 
countered  that  safety  requirements 
called  for  the  current  approach  and 
anything  less  substantial  would 
jeopardize  aircrews,  passengers  and 
cargo.  The  Troop  Carrier  Command, 
which  would  actually  use  the  aircraft, 
was  openly  hostile  to  the  whole  idea 
and  seemed  reluctant  to  get  involved.'^ 
Such  confused  inputs  made 
technological  innovation  extremely 
difficult. 

All  program  problems,  while  dis¬ 
cernible  on  the  home  front,  were  fully 
realized  only  on  the  battlefront.  From 
early  May  until  July  1943,  the  gliders 
were  poised  in  North  Africa  for  the 
impending  invasion  of  Sicily.  One 
observer,  Lieutenant  Holland  Fetters, 
traveled  through  the  various  echelons 
in  this  theater  just  before  the  invasion. 


Serving  as  an  aide  to  the  Special 
Assistant  to  the  Secretary  of  War  for 
Air,  Mr.  Richard  DuPont,  Fetters  wit¬ 
nessed  introduction  of  this  new  tech¬ 
nology  to  warfare.  His  incredibly  rich 
report  from  this  trip  revealed  the  de¬ 
plorable  treatment  the  glider  faced  in 
Africa.  It  revealed  the  ultimate  conse¬ 
quences  this  innovation  met  in  the 
face  of  an  unsupportive  ideology. 

Levels  of  Command 

Fetters  noted  different  perceptions 
about  gliders  at  the  various  command 
levels.  Generals  gloated  about  their 
units’  abilities  to  field  and  maintain 
the  new  aircraft.  The  majors  and  cap¬ 
tains  at  the  depot  level  commented  on 
the  lack  of  parts  and  tools  needed  to 
assemble  gliders. 


Soldiers  instead  impressed  the  lieu¬ 
tenant  with  their  apathy,  but  he  was 
not  surprised  given  the  low  priority 
assigned  to  their  task.  All  units  were 
undermanned,  poorly  trained,  and 
underequipped.  Fetters  wrote  that 
“nothing  will  improve  until  we  outfit 
these  units  and  treat  the  men  as  we 
should.”'* 

Fetters  encountered  a  reality  very 
different  than  the  picture  painted  for 
him  at  higher  headquarters.  Those 
offices,  however,  were  preparing  plans 
for  the  Allied  invasion  of  Sicily.  Those 
plans  reflected  the  reality  air  com¬ 
manders  perceived  and  their  prevail- 


Finally,  Fetters  met  soldiers  respon¬ 
sible  for  actually  doing  the  work  and 
was  appalled  by  the  working  condi¬ 
tions  and  products  turned  out.  At  one 
base,  he  found  only  eight  serviceable 
gliders  out  of  28  he  inspected,  and 
they  needed  significant  work  to  be 
airworthy.  Gliders  arrived  with  parts 
kits  missing  and  in  unmarked  crates. 
When  the  aircraft  sections  were  lo¬ 
cated,  crews  found  assembly  impos¬ 
sible  because  the  Ford  fuselage  did 
not  match  the  Waco  wings  which  did 
not  match  the  Cessna  empennage, 
etc.  The  gliders  themselves  demanded 
that  maintainers  show  initiative,  cre¬ 
ativity  and  resourcefulness. 
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Over  2000  C  130  Hercules  transports  have  been  built,  making  C-I30s  the  longest  production 
run.  more  than  35  years,  of  any  military  transport. 


ing  ideology  of  warfare.  Above  all,  the 
drive  for  air  force  independence  influ¬ 
enced  air  leaders.  Even  though  the 
effort  was  to  be  a  joint  operation,  em¬ 
ploying  sea,  ground  and  air  forces,  the 
airmen  stuck  to  their  narrower  outlook. 

The  British  Style 

The  British,  partners  in  this  inva¬ 
sion,  supplied  the  overall  air  com¬ 
mander,  Sir  Arthur  Tedder,  who  was 
adamant  that  the  air  force  remain  un¬ 
fettered  by  ground  and  naval  planning 
and  operations.  Ground  and  naval 
commanders,  however,  reasonably 
asked  to  know  how  much  air  support 
to  expect  over  the  landing  zones.  Wing 
Commander  Leslie  Scarman ,  Tedder’s 
personal  assistant,  said  noanswerwas 
forthcoming.  Scarman  wrote,  “His  at¬ 
titude  then,  as  always,  was  Tell  me 
what  you  want  done  and  1  will  deliver 
in  my  own  style.”’ 

Powerfully  reinforced  by  their  ally, 
American  flyers  continued  to  place  a 
low  priority  on  gliders.  Their  overrid¬ 
ing  concern  about  independence  and 
the  bombing  missions  in  support  of 
the  invasion  produced  a  skepticism 
about  operation  LADBROKE  (the 
glider  assault)  and  caused  foot-drag¬ 
ging  and  delays  in  planning  air  routes 
for  the  mission.  The  airmen’s  intransi¬ 
gence  irked  General  George  S.  Patton 
who  asked  the  naval  commander  to 
provide  air  cover.  He  fumed,  “lyjou 


can  get  your  Navy  planes  to  do  any- 
thingyou  want.butwecan’tgettheAir 
Force  to  do  a  [expletive  deleted] 
thing!’’’' 

Plans  called  for  the  British  to  supply 
glider  pilots  while  the  Americans  would 
pilot  the  cargo  aircraft,  the  C-4  7,  which 
served  as  the  tug.  The  British  had  used 
gliders  previously  in  the  North  African 
campaign,  so  many  pilots  had  combat 
experience.  What  they  lacked  was  fly¬ 
ing  time  in  the  CG-4.  The  rushed  but 
very  recent  delivery  of  gliders  from  the 
United  States  to  Africa,  combined  with 
the  logistics  problems  in  the  theater, 
resulted  in  RAF  pilots  with  only  two 
hours  behind  the  controls  of  the  CG-4 
before  flying  into  combat.’” 

A  Challenging  Task 

The  AAF  C-47  pilots  faced  the  chal¬ 
lenging  task  of  towiiig  the  gliders  from 
Africa  to  Sicily  at  night,  getting  the 
aircraft  into  the  proper  position  to 
release  the  glider,  then  returninghome 
—  a  10-hour  mission.  Of  course  the 
Axis  powers  tried  to  stop  the  Allies 
with  antiaircraft  artillery,  and  the 
weather  could  further  complicate  af¬ 
fairs.  Pilots  carried  much  anxiety  with 
them  on  this  mission,  but  they  also 
carried  their  notions  of  the  gliders’ 
usefulness  in  combat. 

The  evening  of  the  planned  inva¬ 
sion,  July  9,  1943,  General  Dwight  D. 


Eisenhower  agonized  about  the  deci¬ 
sion  to  launch  the  aircraft  in  the  face 
of  the  gale  that  was  blowing  in  the 
Mediterranean.  Realizing  that  scrub¬ 
bing  the  missions  would  mean  a 
month’s  delay  until  the  moon  would 
again  cast  enough  light,  Eisenhower 
gambled  that  the  planes  would  get 
through.  The  rough  weather  height¬ 
ened  complexity  of  the  pilots’  tasks. 
With  so  many  inexperienced  people 
at  the  controls,  chaos  reigned.  Tugs 
got  lost  and  returned  to  Africa.  One 
released  its  glider  over  Malta  —  half 
way  to  Sicily  and  Eisenhower’s  com¬ 
mand  post.  Most  arrived  near  Sicily 
but  when  the  Germans  opened  fire  on 
the  aircraft,  many  C-47s  immediately 
released  theirgliders. '“Those  that  con¬ 
tinued  had  difficulty  finding  the  drop 
zone  and  simply  guessed  where  to 
release  the  gliders.  All  problems  of  the 
C-47  aircrews  suddenly  became  the 
glider  crews’  dilemmas. 

In  the  darkness,  over  unfamiliar 
territory,  the  glider  aircrews  had  no 
control  over  their  rate  of  descent  and 
very  little  over  their  landing  site.  Many, 
unfortunately,  landed  in  the  sea,  and 
the  Waco  quickly  sank  up  to  the  wing 
panels.  With  no  escape  hatches  built 
for  the  airmen  and  soldiers,  hundreds 
of  men  lost  their  lives  in  the  Mediter¬ 
ranean.  Those  landing  on  Sicily  could 
do  little  more  than  hope  for  a  mild 
crash.  Gliders  that  smashed  into  trees 
and  had  wings  ripped  off,  but  other¬ 
wise  remained  intact,  were  common. 
Some  ran  over  rock  walls  which  ru¬ 
ined  the  aircraft  but  not  the  men  and 
equipment  inside. 

Mission  Failed 

Others  were  not  so  lucky.  Some 
gliders  crashed  before  slowing  signifi¬ 
cantly,  and  many  soldiers  never  faced 
the  enemy.  In  short,  most  of  the  glider 
invasion  force  landed  more  than  five 
miles  from  the  drop  zone.  In  the  bad 
weather  and  confusion  of  combat,  the 
Allies  lost  or  killed  most  of  their  own 
troops.’”  A  glider  assault  on  Sicily 
would  have  been  difficult  under  ideal 
conditions.  On  July  9,  1943,  the  mis¬ 
sion  failed. 
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Historians  have  debated  the  use  of 
glider  and  airborne  troops  during  the 
invasion  of  Sicily.  lohn  Keegan,  for 
example,  in  his  acclaimed  The  Second 
World  War,  assesses  airborne  opera¬ 
tions  in  general,  including  gliders,  in 
this  summation; 

There  is  a  possibility  that  a  com¬ 
bination  of  luck  and  judgement 
will  deposit  him  [the  airborne 
soldier]  and  his  comrades  be¬ 
yond  the  jaws  of  danger,  enable 
them  to  assemble  and  allow 
formed  airborne  units  to  go  for¬ 
ward  to  battle;  but  the  probabil¬ 
ity  is  otherwise. 

Surprisingly,  and  with  little  evi¬ 
dence.  Keegan  claims  that  Sicily  and 
Normandy  were  the  only  examples 
which  “evadeldj  the  probabilities." 
Carlo  D’Este  counters  Keegan’s  evalu¬ 
ation  of  Sicily,  but  seconds  his  evalu¬ 
ation  of  airborne  and  glider  opera¬ 
tions.  Sicily  failed,  he  argues,  because 
commanders  did  not  take  into  account 
the  difficult  terrain  and  the  relatively 
untested  airborne  tactics.  He  believes 
they  were  focused  instead  on  inter- 
Service  rivalries  and  on  planning  op¬ 
erations  which  emphasized  the 
strength  of  each  Service.  My  thesis 
holds  that  gliders  offered  no  compara¬ 
tive  advantage  to  the  airmen  in  this 
inter-Service  struggle,  and  the  difficul¬ 
ties  on  the  home  front  revealed  their 


ambivalent  attitudes  toward  this  new 
technology.  Like  D’Este,  1  think  com¬ 
bat  operations  in  Sicily  proved  the 
glider  failed,  and  1  think  Keegan  out¬ 
lines  the  specific  problems  airmen 
failed  to  overcome.  Our  opinions  and 
debates  can  contribute  to  policy  mak¬ 
ing  today,  but  contemporary  assess¬ 
ments  seemed  clear. 

American  airmen  quickly  offered 
their  assessment.  One  C-47  pilot  said 
he  “would  rather  not  have  anything  to 
do  with  these  parasites.”  Another  said 
that  his  “main  objection  other  than 
the  glider  being  a  pile  of  junk,  was  the 
decrease  in  flying  speed  of  the  tug 
ship,  with  the  glider  in  tow.”  The  pilots 
volunteered  to  Lieutenant  Fetters  a 
solution  to  the  maintenance  night¬ 
mare  the  gliders  caused:  “The  hell 
with  the  maintenance,  we  don’t  want 
to  tow  them  around  anyway.”-’ 

After  many  days  in  Africa  and  Sicily 
and  many  animated  conversations 
with  the  troops.  Fetters  concluded  the 
report  to  hiscommandinggeneral  with 
the  grim  observation  that  “fijn  gen¬ 
eral,  the  personnel  in  the  North  Afri¬ 
can  Theater  have  little  care  or  concern 
for  gliders. ”” 

The  AAF  tried  to  address  problems 
with  glider  technology  in  the  months 
after  the  assault.  Specific  recommen¬ 
dations  for  CG-4  improvements  ranged 


from  better  cockpit  instrumentation  to 
escape  hatches.  In  fact,  changes  be¬ 
came  so  substantial  that,  instead  of 
designing  a  CG-4B  (an  updated  ver¬ 
sion  of  the  basic  model).  Wright  Field 
asked  Waco  to  design  the  CG-15,  a 
much  more  capable  aircraft.-  ’ 

Glider  Pilot  Training 

The  glider  pilot  training  program 
began  graduating  Americans  fully 
qualified  to  fly  in  combat,  and  produc¬ 
tion  problems  diminished.  But  gliders 
were  far  from  finding  a  home  in  the 
AAF.  General  officers  regularly  called 
for  smaller  production  quantities  or 
outright  cancellation  of  the  program. 

Increased  battlefield  effectiveness 
failed  to  squelch  the  critics.  Most  in¬ 
dicative  of  the  enduring  strength  of  the 
Air  Force  drive  for  independence  was 
the  call  at  the  end  of  the  war  for  gliders 
with  engines,  thus  eliminating  the  need 
for  a  tug.  All  along  the  glider  necessi¬ 
tated  cooperation  with  ground  forces 
which  airmen  found  uncomfortable. 
This  proposal  allowed  airplanes  to  be 
airplanes.  The  oxymoron  —  multi¬ 
engined  glider  —  was  the  AAF’s  most 
succinct  commentary  on  glider  tech¬ 
nology. 

Many  officers  and  companies,  in¬ 
cluding  Waco,  worked  diligently  in 
1945  to  solve  the  problem,  but  top  air 
leaders  knew  these  steps  were  part  of 
an  awkward  transition  to  cargo  as¬ 
sault  aircraft,  like  the  C-123  of  the 
Korean  Conflict  and  the  C-130  of  to- 
day.^''  Once  all  parties  recognized  the 
absurdity  of  “powered  gliders,”  cargo 
gliders  and  the  niche  they  were  in¬ 
tended  to  fill  left  military  minds  until 
Vietnam.  Then,  the  importance  of  in¬ 
serting  men  and  material  at  the  battle- 
front  while  maintaining  the  element  of 
surprise  compelled  the  Army  to  de¬ 
velop  and  procure  its  own  air  force 
built  around  the  aeronautical  technol¬ 
ogy  of  the  helicopter. 

The  glider,  an  example  of  failed 
innovation,  revealed  howencompass- 
ing  the  technological  innovation  pro¬ 
cess  was.  The  introduction  of  gliders 
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into  combat  required  actions  from 
military  officials  in  Washington,  D.C., 
at  Wright  Field,  in  North  Africa  and 
Sicily.  It  touched  firms  in  the  aviation 
industry  and  impacted  civilian 
agencies  which  administered  the  mo¬ 
bilization.  In  short,  it  demanded  manu¬ 
facturing,  administrative  and  organi¬ 
zational  innovations  in  the  military 
and  in  business. 

Frustrations 

This  complexity  is  familiar  to  ac¬ 
quisition  professionals  today.  Some 
may  find  comfort  in  learning  that  our 
experiences  and,  perhaps,  frustrations 
are  not  new.  Others  may  express  dis¬ 
appointment  that  some  things  never 
change.  In  this  instance,  the  program 
suffered  because  the  logic  of  this  tech¬ 
nology  and  its  mission  countered  pre¬ 
vailing  Air  Force  doctrine. 

Ideas  matter.  Discerning  the  most 
important  ideas  from  the  crush  of  is¬ 
sues  we  deal  with  in  acquisition  is 
difHcult.  Placing  our  efforts  in  an  ap¬ 
propriate  historical  context  will  help 
leaders  at  all  levels  communicate  pri¬ 
orities  more  clearly  and  improve 
chances  for  successful  technological 
innovation. 
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24.  Raymond  J.  Snodgrass,  The  AAF 
Glider  Program,  November  1944  to 
January  1 947  (Air  Materiel  Command 
History  Office,  Intelligence  Depart¬ 
ment,  Study  #217,  1947)  pp.  54-5. 
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TIPS  FOR  AUTHORS 


SEND  US  YOUR  ARTICLES 
FOR  PROGRAM  MANAGER 


Journal  of  the 

Defense  Systems  Management  College 


The  editors  of  Program  Manager, 
DSMC’s  bimonthly  journal,  are 
interested  in  your  thoughts  on 
policies,  processes,  trends,  and 
events  in  the  areas  of  program  man¬ 
agement  and  defense  acquisition.  We 
invite  you  to  submit  articles  and  share 
your  experiences.  We  are  interested 
in  lessons  you  have  learned  through 
your  acquisition  experiences,  success¬ 
ful  and  otherwise. 

Beyond  the  demand  for  good  gram¬ 
mar,  we  have  some  tips  for  prospec¬ 
tive  authors.  Consistency  and  unifor¬ 
mity  are  essential.  The  renowned 
stylist  William  Strunk,  |r.,  said,  “If 
those  who  have  studied  the  art  of 
writing  are  in  accord  on  any  one  point, 
it  is  this:  the  surest  way  to  arouse  and 
hold  the  attention  of  the  reader  is  by 
being  specific,  definite  and  concrete." 


substantial  editorial  changes,  the 
DSMC  Press  staff  clears  edited  copy 
with  the  author. 

If  possible,  clear  articles  through 
your  public  affairs  office  or  an  equiva¬ 
lent  authority.  Most  of  the  articles  we 
publish  are  reviewed  routinely  and 
cleared  by  the  Director,  Security  Re¬ 
view,  Office  of  the  Assistant  Secretary 
of  Defense  for  Public  Affairs.  When 
necessary,  articles  are  reviewed  by 
DSMC  faculty  members  with  exper¬ 
tise  in  the  subject  matter.  The  receipt 
of  your  manuscript  will  be  acknowl¬ 
edged  within  five  working  days. 

Length  and  Graphics 

The  Basics:  We  prefer  to  receive  a 
paper  copy  of  your  manuscript, 
doubled-spaced  and  printed  on  one 
side  of  the  paper.  If  pos- 


flexible  regarding  length,  but  we  prefer 
2,000-3,000  words — about  10 
doubled-spaced  pages  each  having  a 
1-inch  border  on  all  sides.  Don’t  feel 
constrained  by  length  requirements; 
make  your  statement  in  the  most  di¬ 
rect  way.  regardless  of  length. 

We  use  figures,  charts  and  photo¬ 
graphs.  Color  is  acceptable,  but  we 
prefer  glossy,  black-and-white  photo¬ 
graphs  measuring  5  by  7  or  8  by  10 
inches.  We  cannot  guarantee  the  re¬ 
turn  of  photographs.  Include  brief, 
numbered  cutlines  keyed  to  the  pho¬ 
tographs.  Place  a  corresponding  num¬ 
ber  on  the  lower  left  corner,  reverse 
side  of  the  photographs.  With  this 
exception,  do  not  write  on  photo¬ 
graphs.  Photocopies  of  photographs 
are  not  acceptable.  Charts  and  figures 
also  should  be  provided  on  a  com- 


Style 

Write  in  the  first  person;  i.e.,  /,  we 
our,  and  use  you  often.  Active  verbs 
are  best.  Write  naturally,  in  active 
voice,  and  avoid  stiltedness.  Except 
for  a  change  of  pace,  keep  most  sen 
tences  to  25  words  or  less  and  para 
graphs  to  six  sentences.  We  use  the 
Associated  Press  Style  Manual  as  a 
reference,  and  encourage  its  use  by 
prospective  Program  Managerauthors. 
We  reserve  the  right  to  edit  for  clarity 
and  space  limitations. 


Published  articles  will  include 
your  byline  and  a  brief 
biography.  When  _ 

there  are 


sible,  send  a  copy  of  your 


manuscript  on  a  5  1/4 


or  3  1/2-  inch  com 


puter  diskette, 
using  either 
WordPerfect 


formatted 


(ASCII) 
version 
We  are 


Continued  on  page  35 


puter  diskette  and  in  addition  to  a 
paper  copy.  These  charts  and  figures 
should  be  sharp  and  clear  with 
legible  information  and 
captions.  We  prefer 
camera-ready  art. 
but  the  DSMC  Vi¬ 
sual  Arts  and  Print¬ 
ing  and  Duplicat¬ 
ing  Services 
Division  can 
work  with 
sketches  if 
they  are  clear 
and  precise. 
Authors  are 
responsible  for 
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COUNTERPOINT 


DEPARTMENT  OF  THE  NAVY 
STRATEGIC  SYSTEMS 
PROGRAMS  OFFICE 

A  Premier  Program  Management  Institution 

Ibrahim  A.  Ashie 


My  purpose  in  writing  this  article  is 
to  discuss  some  issues  raised 
by  “The  Metamorphosis  of  Pro¬ 
gram  Management,  Rainbow  of 
Change,”  by  Colonel  W.  E.  Cole, 
USAF.  It  appeared  in  the  May-June 
1993  Program  Manager.  Also,  I  ex¬ 
plain  briefly  the  functions  of  the  De¬ 
partment  of  the  Navy’s  first  program 
management  office,  relative  to  the  so- 
called  new  management  paradigm  of 
Total  Quality  Management  (TQM). 

The  Japanese  did  not  devise  the 
new  management  concept.  The  con¬ 
cept  and  its  components  have  been 
described  in  Department  Of  Defense 
(DOD)  directives,  instructions,  mili¬ 
tary  specifications,  standards,  docu¬ 
ments  and  pamphlets  since  the  end  of 
World  War  II. 

U.S.  Business  after 
World  War  II 

The  U.S.  business  community  did 
not  use  these  managerial  tools  devel¬ 
oped  by  DOD  immediately  after  the 
war  because  there  was  a  vast  domestic 
market  ready  to  consume  whatever  it 
manufactured.  Furthermore,  the  eco¬ 
nomic  environment  of  the  country  was 
characterized  by  a  need  for  capital 


Mr.  Ash  ie  is  a  System  Engineer,  Plans, 
Programs  and  Training  Branch,  Strate¬ 
gic  Systems  Programs,  Department  of 
the  Navy. 


formation  dictated  by  the  financial 
market  (Wall  Street),  with  stockhold¬ 
ers’  lust  for  instant  reward. 

These  conditions  led  companies  to 
employ  chiefexecutive  officers  (CEOs) 
who  could  bring  the  most  end-of-the- 
year  profits  to  the  company,  since 
companies’  performances  were  evalu¬ 
ated  by  the  bottom  line  of  their  quar¬ 
terly  and  annual  financial  reports. 
Long-range  planning  was  uncommon 
since  most  of  these  CEOs  were  con¬ 
cerned  only  with  short-range  results. 
The  concept  of  efficient  and  effective 
use  of  resources  was  not  a  consider¬ 
ation  as  long  as  profits  kept  coming  in. 

U.S.  Air  Force  Adoption 
Of  the  New  Management 
Concept 

Contrary  to  Colonel  Cole’s  state¬ 
ment  that  the  Air  Force  Materiel  Com¬ 
mand  is  developing  a  twin  to  this  new 
management  approach,  which  is 
named  the  Integrated  Product  Devel¬ 
opment  (IPD),  the  concept  had  al¬ 
ready  been  published  in  the  form  of 
MILSTD-499  (USAF)  17  July  1969 
(EngineerlngManagement).  This  Stan¬ 
dard  had  all  the  building  blocks  or  the 
ingredients  of  the  so-called  TQM. 

In  their  textbook.  Managing 
(A  Contemporary  Introduction), ]oseph 
L.  Massie  and  John  Douglas  pointed 
out  that  a  manager  must  constantly 
develop  the  vision  and  the  wisdom  for 
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putting  the  building  blocks  of  man¬ 
agement  into  a  meaningful  whole.  They 
identified  these  building  blocks  to  be: 

1.  Theory  and  Practice 

2.  Operations  and  Activities 

3.  Types  of  Knowledge 

4.  Functions  and  Processes 

5.  Skills  and  Interests. 

Since  most  DOD  program  manag¬ 
ers  were  specialists  rather  than  gener¬ 
alists,  they  were  not  able  to  utilize  full 
potentials  of  MlLSTD-499.  or  to  use 
them  effectively. 


Formation  of 
First  Program  Office 

On  January  7,  1957,  an  organiza¬ 
tion  then  called  the  Special  Project 
Office  (SPO)  within  the  Department  of 
the  Navy  was  established  to  manage 
the  underwater  launching  of  ballistic 
missiles.  The  functional  subsystems 
of  the  new  weapon  system  were  estab¬ 
lished  to  delineate  clearly  interfaces 
that  also  defined  the  SPO  organiza¬ 
tional  structure  and  which  remain  to 
this  day.  Figure  1,  reproduced  from 
the  History  of  the  FBM  System  by 
Lockheed  Missile  and  Space  Com¬ 
pany  Inc.,  shows  the  SPO  structure. 

The  current  name  of  the  organiza¬ 
tion  is  the  Strategic  Systems  Programs 
(SSP)  command.  When  program  man¬ 
agement  became  popular  in  the  early 
1970s,  the  Navy  designated  this 
agency  as  Program  Management  Of¬ 
fice  No.  1  (PM-1). 

Subsequently,  the  Navy  performed 
a  study  on  occupational  information, 
resulting  in  a  guide  entitled  Project 
Management  Positions  in  the  Depart¬ 
ment  of  the  Navy,  October  1 98 1 .  It  was 
modeled  after  the  SSP  organizational 
structure. 


A  brief  discussion  of  the  SSP  func¬ 
tions,  relative  to  issues  raised  by  Colo¬ 
nel  Cole,  follows: 

1 .  Product  and  Process-oriented  Or¬ 
ganization/Integrated  Product  Devel¬ 
opment.  As  seen  in  Figure  1,  SSP’s 
formation  had  this  purpose  in  mind. 

2.  Teams.  Each  functional  branch 
of  SSP  (for  example  SP-27  the  Missile 
Branch)  comprised  a  team  of  engi¬ 
neers,  program  analysts,  logisticians, 
budget  analysts  and  uniformed  Navy 
personnel  experienced  in  operan-  n.s 
of  the  Fleet  Ballistic  Missile  (S  i'M) 
submarines.  The  original  team  of  the 
organization  was  credited  with  devel¬ 
opment  of  the  Program  Evaluation 
and  Review  Technique  (PERT)  which 
is  used  widely  in  program  manage¬ 
ment. 

This  tool  was  modified  by  the  Na¬ 
tional  Aeronautical  and  Space  Admin¬ 
istration  (NASA)  and  called  NASPERT. 
It  was  used  in  the  system  acquisition 
and  management  of  the  space  pro¬ 
gram  in  its  early  years. 

3.  Customer  Needs.  Throughout 
development  of  the  FBM  system. 


FIGURE  I.  Special  Projects  Office  Organization  — 


(NOTE:  MIT-IL  =  Instrumentation  Laboratory  of  MIT;  now  called  the  Draper  Laboratory.) 
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operational  Navy  personnel  (ultimate 
users  of  the  system)  have  been  active 
participants. 

They  were  and  are  consulted  at 
every  stage  of  program  development 
and  in  the  design  and  placing  of  equip¬ 
ment  in  both  the  submarines  and  at 
the  training  facilities. 

4.  Empowerment/Pride  in  Owner¬ 
ship.  Principal  engineers  and  their 
teams  are  responsible  for  developing 
budgets  in  response  to  program  direc¬ 
tives  and  requirements.  The  team  ini¬ 
tially  presents  the  budget  to  the  branch 
management  for  internal  review  and 
corrections. 

The  same  team  then  presents  the 
budget  to  the  command’s  Board  Of 
Directors  (BODs),  and  answers  BOD 
questions.  Upon  budget  approval,  the 
team  with  the  help  of  the  branch  bud¬ 
get  analysts  initiates  Procurement 
Request  (PR)  for  the  acquisition  of  its 
subsystem .  Then ,  the  team  works  with 
contracting  and  legal  personnel  to 
compose  the  Request  For  Proposal. 
The  team  evaluates  the  technical  por¬ 
tion  of  the  proposal,  performs  fact¬ 
finding  with  the  winning  contractor, 
and  participates  in  contract 
negotiations. 

After  contract  award,  the  team  starts 
monitoring  the  contract  for  conform¬ 
ance  to  cost,  schedule  and  perfor¬ 
mance  (CSP)  requirements,  with  the 
help  of  command  plant  technical  rep¬ 
resentatives  and  Defense  Logistic 
Agency  pjersonnel. 

The  pride  of  program  ownership  is 
enhanced  by  encouraging  every  SSP 
staff  member  to  visit  the  FBM  training 
facilities  or  observe  missile  firing  at 
Cape  Canaveral,  Fla.,  or  participate  in 
submarine  demonstration  and  shake- 
down  operations  (DASO),  or  visit  a 
submarine  in  port. 

5.  In-process  Quality  Control/Statis¬ 
tical  Quality  Control.  (Juality  control 
is  performed  at  every  stage  of  each 
subsystem  development  cycle.  There 


are  weapons  specifications  to  be  met 
for  each  critical  item  and  for  each 
subsystem.  Statistical  quality  control 
is  used,  where  necessary,  to  satisfy 
tolerance  requirements  during  manu¬ 
facture  of  components. 

6.  Continued  Process/Product  Im¬ 
provement.  In  Figure  1  of  the  SSP 
organization,  you  can  see  the  major 
team  has  two  notable  university  units 
as  members:  the  Draper  Laboratory  of 
the  Massachusetts  Institute  of  Tech¬ 
nology  and  the  Applied  Physics  Labo¬ 
ratory  of  the  lohns  Hopkins  Univer¬ 
sity. 

These  laboratories,  the  Atomic  En¬ 
ergy  Commission  (now  part  of  the 
Department  of  Eneigy)  and  Navy  labo¬ 
ratories  work  together  to  improve  con¬ 
tinuously  the  FBM  system  with  state- 
of-the-art  technology.  The  training 
facility  and  the  fleet  personnel  provide 
suggestions  for  system  improvement. 
These  personnel  generate  trouble  and 
failure  reports  (TFRs)  for  hardware, 
software  and  documentation  for  the 
purpose  of  system  improvement.  These 
improvements  have  helped  develop 
the  weapons  system  from  the  original 
POLARIS  through  POSEIDON  to  the 
present  TRIDENT  II  system. 

7.  Collocation.  The  staff  of  SSP  is 
centrally  located,  which  facilitates 
face-to-face  communication  and  in¬ 
stantaneous  exchange  of  ideas  among 


lawyers,  engineers,  financial  resource 
analysts,  program  analysts  and  con¬ 
tracting  personnel.  This  collocation 
provides  a  cohesive  and  tolerant  team 
atmosphere. 

Conclusion 

From  the  above  discussions,  it  can 
be  concluded  that  TQM  and  its  other 
names  were  not  of  Japanese  origin,  but 
have  been  in  existence  since  1957. 
They  have  been  part  of  the  operating 
procedures  of  the  Department  of  the 
Navy  Strategic  Systems  Programs  com¬ 
mand. 

National  and  military  security  has 
shielded  this  command  from  the  busi¬ 
ness  world. 

Now  that  the  Cold  War  is  ended, 
the  Defense  Systems  Management  Col¬ 
lege  should  consider  using  this  com¬ 
mand  as  a  program  management  model 
and  encourage  DOD  components  to 
use  this  command  as  an  internship 
institution  for  prospective  program 
managers. 
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Continued  from  page  31 


submitting  photos  and  other  illustra¬ 
tions  pertinent  to  their  manuscripts. 

Attribute  all  references  you  have 
used  in  researching  your  article.  Use 
separate  footnotes,  identified  at  the 
appropriate  place  in  the  copy. 

Be  wary  of  using  copyrighted  mate¬ 
rial.  It  is  generally  felt  that  Section  107 
of  Title  17,  United  States  Code,  "Limi¬ 
tations  on  Exclusive  Rights:  Fair  Use,” 
clears  the  way  for  quoting  short  pas¬ 
sages  of  copyrighted  material  in  a 
scholarly  or  technical  article  to  illus¬ 
trate  or  clarify  the  author’s  observa¬ 
tions.  It  also  permits  summarizing 
copyrighted  addresses  and  articles  with 
brief  quotations.  Lengthy  use  of  copy¬ 
righted  material  requires  written  per¬ 
mission  from  the  copyright  holder. 
Likewise,  if  you  are  the  copyright 
holder,  your  cover  letter  should  ex¬ 
plicitly  state  that  the  Defense  Systems 
Management  College  has  permission 
to  publish  your  material  in  Program 
Manager. 

Stories  that  appeal  to  our  readers, 
who  are  senior  military  personnel  and 
civilians  in  the  program  management/ 
acquisition  business,  are  those  taken 
from  your  own  experience  rather  than 
pages  of  “researched  information.” 

Again,  be  sure  to  double-space 
your  copy  and  use  only  one  side  of 
the  paper.  We  appreciate  your 
readership,  and  interest  in  Program 
Manager. 

If  you  need  to  talk  to  an  editor, 
please  call: 

Esther  M.  Farria  or  Robert  W.  Ball 
at  (703)  805-2892/3056;  DSN  655- 
2892/3056:  or  send  a  letter  addressed 
to: 


DEFENSE  SYST  MGMT  COLG 
ATTN  DSMC  PRESS 
9820  BELVOIR  ROAD 
SUITE  G38 

FT  BELVOIR  VA  22060-5565. 


The  Air  Force  Institute  of  Technology  (AFIT), 
Department  of  Contracting  Management, 
School  of  Systems  and  Logistics,  needs  an 
instructor  of  Contracting  Management. 

The  AFIT  teaches  systems  acquisition  man¬ 
agement,  logistics  management,  contracting 
management,  cost  analysis  and  related  courses 
to  Air  Force  and  DOD  military  and  civilian 
personnel  in  programs  leading  to  master’s  de¬ 
grees,  and  in  programs  of  continuing  profes¬ 
sional  education.  Responsibilities  primarily 
include  instruction  in  the  contracting  manage¬ 
ment  program  of  professional  continuing  edu¬ 
cation  courses,  ranging  from  lower-level  un¬ 
dergraduate  to  graduate-level  courses. 
Responsibilities  also  will  include  course  de¬ 
velopment  and  administration  and  manage¬ 
ment,  along  with  consulting  and  research  for 
DOD  activities. 

The  3-year  appointment  is  under  the  Institute’s 
Schedule  A  excepted  appointment  system. 
Salary  is  negotiable  within  the  academic  rank 
for  which  the  candidate  qualifies.  Applicants 
must  be  U.S.  citizens.  Submit  resumes  and 
salary  requirements  to  Colonel  Paul  T.  Welch, 
USAF,  Dean,  School  of  Systems  and  Logistics 
(AFIT/LS),  2950  P  Street,  Wright- Patterson 
AFB  OH  45433-7765.  Address  questions  to 
Mr.  Dyke  McCarty,  telephone  (513)  255-7777, 
Ext.  3225. 
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ON-LINE,  TECHNOLOGY-BASED 


DOD  ACQUISITION  HISTORICAL  CENTER 
BEGINS  SYSTEM  DEVELOPMENT  PHASE 

Officially  Open  for  Business  in  Spring  1 994 


The  effort  to  establish  the  Depart¬ 
ment  of  Defense  (DOD)  Acquisi¬ 
tion  Historical  Center  at  the  De¬ 
fense  Systems  Management 
College  (DSMC),  a  project  begun  in 
1992  by  the  Under  Secretary  of  De¬ 
fense  (Acquisition),  has  recently  com¬ 
pleted  the  concept  exploration  phase 
and  entered  the  demonstration  and 
validation  phase  for  system  develop¬ 
ment. 

The  DSMC  Commandant,  Brig  Gen 
(Sel.)  Claude  M.  Bolton,  Jr.,  USAF, 
approved  the  project’s  acquisition 
strategy  and  system  selection,  and  di¬ 
rected  development  of  the  electronic 
finding  aids  database  prototype. 

Already  collecting  acquisition  in¬ 
formation  and  open  to  researchers  on 
a  case  basis,  the  Center  —  also  re¬ 
ferred  to  as  the  “acquisition  archives” 
—  will  open  officially  in  the  spring  of 
1994  on  a  part-time  basis  using  in¬ 
terim  manual  procedures.  Once  open, 
the  Center  will  add  a  new  dimension 
to  the  research  capability  of  DOD  per¬ 
sonnel.  Plans  call  for  the  Center  to  be 
fully  operational  by  mid-FY  1 997,  con¬ 
tingent  upon  available  funding. 

The  USD(A)  established  the  Cen¬ 
ter  at  DSMC  to  meet  the  need  for  a 
central  DOD  repository  for  defense 
acquisition  information.  The  Center’s 
mission  is  to  accomplish  that  goal  and 
become  an  electronic  forum  within 
DOD  for  collecting,  storing  and  re¬ 
trieving  historical  acquisition  infor¬ 
mation,  and  to  support  the  overall 
DSMC  mission  of  improving  manage¬ 
ment  of  the  acquisition  process. 


Optical  Disk  Technology 
Reduces  Storage 
Requirements 

The  Center’s  system  will  incorpo¬ 
rate  state-of-the-art  imaging  and  opti¬ 
cal  disk  technology  to  reduce  storage 
requirements  and  provide  expeditious, 
user-friendly  workstation  on-line 
search  service.  Remote  access  will  be 
provided  via  the  Defense  Data  Net¬ 
work  and  Internet  or  a  modem  con¬ 
nection.  The  system  will  allow  access 
to  the  DSMC  library  database  through 
DSMC’s  electronic  campus  project. 
Ultimately,  the  Center  plans  to  com¬ 
pile  a  clearinghouse  finding  aids  data¬ 
base  of  acquisition  information  held 
in  government  and  nongovernment 
repositories. 

Potential  users  include  acquisition 
managers,  students  of  the  Defense 
Acquisition  University  consortium 


members,  and  other  researchers  from 
DOD,  other  govemmentorganizations, 
industry,  academe  and  the  public. 
Potential  donors  include  the  Office  of 
the  Secretary  of  Defense.  Military  Ser¬ 
vices  and  other  DOD  organizations, 
government  and  industry  acquisition 
activities,  academe  and  individuals. 

Collects  Donated  Copies  of 
Nonsensitive  Information 

Copies,  not  originals,  of  classified 
and  unclassified  information  are  col¬ 
lected  in  all  media.  Donations  are 
voluntary.  Donors  from  DOD  aie  ex¬ 
pected  to  adhere  to  applicable  stat¬ 
utes  and  regulations  of  DOD  and  the 
National  Archives  regarding  records 
disposal  procedures.  Unclassified  in¬ 
formation  donated  is  considered  to  be 
nonsensitive  and  “publicly  releas¬ 
able,”  or  to  meet  one  of  the  nine  ex¬ 
emptions  under  the  Freedom  of  Infor- 
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Photo  by  Sgt.  Richard  Vigue,  USA 
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mation  Act.  The  Center  does  not  col¬ 
lect  material  containing  proprietary 
data,  top  secret  or  nuclear  weapons 
material,  commercially  printed  mate¬ 
rial,  information  deemed  sensitive  to 
the  originator  or  donor,  or  duplicate 
information  collected  by  otl-.er  DOD 
activities  such  as  the  Defense  Techni¬ 
cal  Information  Center. 

Items  being  collected  include: 

— Program  m,.ii:igement  office  records 
— Lessons  learned 

— Decision  memoranda  and  policy 
directives 

—Briefing  and  issue  papers 
— Case  studies 

—Personal  papers  relating  to 
acquisition 

— Oral  or  written  histories 
— Research  papers 
—Technical  or  policy  studies  and 
reports 

— Government  handbooks  andguides 
— Contract  and  budget  documents 
—Industry  contractor  records 
— Congressional  hearing  reports. 

For  example,  the  Center  has  col¬ 
lected  records  of  the  Defense  Manage¬ 
ment  Review  (former  Defense  Secre¬ 
tary  Dick  Cheney’s  “DMR”);  various 
records  of  the  Defense  Systems  .Acqui¬ 
sition  Review  Council  (predecessor  to 


the  present  Defense  Acquisition 
Board);  various  records  of  the  F/A-18 
program  office;  lessons  learned  from 
the  Multiple  Subscriber  Equipment 
program;  histories  of  the  Air  Force 
Operational  Test  and  Evaluation  Cen¬ 
ter;  various  records  of  the  Office  of 
Acquisition  Policy  and  Program  Inte¬ 
gration;  and  symposia  proceedings. 

When  the  full  storage  and  retrieval 
capabilities  are  operational,  by  mid- 
FY  1996,  much  of  the  unclassified 


Region  (NCR) 
information  will  be  available  through 
full-text  retrieval  allowing  workstation 
printing.  Classified  information  will 
be  available  on-site  through  prior  ar¬ 
rangement. 

Center  Director  and 
Contractor  Team  in  Place 

The  Center  Director  is  Wilbur  D. 
Jones.  Jr. ,  DSMC’s  Associate  Dean  of 
Information.  He  is  assisted  by  Jane 
Cohen,  DSMC  reference  librarian.  The 
Center  has  contracted  with  the  team 
of  Arist  Corporation,  of  Alexandria, 
Va.,  and  History  Associates,  Inc.,  of 
Rockville,  Md.,  to  continue  the  system 
development  and  operate  the  Center. 

Readers  can  obtain  the  Center’s 
collection  and  user  policies  by  writing 
to: 

DEFENSE  SYST  MGMT  COLG 

ATTN  DIR  ACQ.HIST  CTR 

9820  BELVOIR  ROAD 

SUITE  G38 

FT  BELVOIR  VA  22060-5565 

Organizations  or  individuals  wish¬ 
ing  to  donate  information  can  write  or 
telephone  Mr.  Jones  at  (commercial) 
703-805-2525  or  (DSN)  655-2525,  or 
Ms.  Cohen  at  703-805-2293  or  655- 
2293. 


DSMC  library  reference  librarians  Maryellen  Tipper  and  Jane  Cohen  check  index  of  material 
held  by  Historical  Center 
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USD(A&T)  ATTENDS 


DSMC  HOSTS  ACQUISITION 
RESEARCH  FORUM 

Joan  L.  Sable 


l^rig  Ccn  (Set.)  Claude  M.  Bolton,  Ir.,  DSMC  Commandant  and  The  Honorable  lohn  M. 
Peuleh.  Under  Secretary'  of  Defense  (Acquisition  and  Technology). 


On  Tuesday  evening.  November  2, 
I W3,  the  Defense  Systems  Man¬ 
agement  College  ( DSMC)  hosted 
an  Acquisition  Research  Forum 
with  The  Honorable  lohn  M.  Deutch, 
Under  Secretary  of  Defense  (Acquisi¬ 
tion  and  Technology)  and  other  De¬ 
partment  of  Defense  (DOD)  officials 
attending.  The  Forum  theme  was  “  Rel¬ 
evancy  of  Acquisition  Research  to 
DOD’s  Unfolding  Acquisition  Chal¬ 
lenges.” 

The  100  faculty  and  staff  attend¬ 
ing,  a  number  from  the  Industrial  Col¬ 
lege  of  the  Armed  Forces  and  Army 
Management  Staff  College,  included; 
Dr.  Deutch:  Dr.  lames  S.  McMichael, 
Director  of  Acquisition  Education, 
Training  and  Career  Development 
Policy;  BrigadierGeneral  (Sel,)  Claude 
M.  Bolton,  [r.,  USAF,  DSMC  Com¬ 
mandant:  Mr.  Gerald  E.  Keightley, 
Executive  Director  of  the  Defense 
Acquisition  University  (DAU);  Dr. 
Walter  B.  LaBerge,  DSMC  Visiting 
Professor:  and  Dr.  Benjamin  C.  Rush, 
DSMC  Dean  of  Faculty. 

The  Forum  opened  with  light  re¬ 
freshments  and  DSMC  interactive  ex- 
hibitsanddisplays.  Subsequently,  dur¬ 
ing  an  award  ceremony,  two  DSMC 
personnel,  Thomas  Dolan,  Ir.,  and 
Donald  M.  Freedman,  received  De¬ 
partment  of  the  Army  Meritorious  Ci¬ 
vilian  Service  Awards  fortheirworkon 


Ms.  Sable,  Research  Associate  of  the 
Research,  Consulting  and  Information 
Division,  DSMC,  organized  the  Forum 
program. 


the  Department  of  Defense  Advisory 
Panel  on  Streamlining  and  Codifying 
Acquisition  Law. 

General  (Sel.)  Bolton  began  the 
Forum  by  stating:  ‘DSMC  remains  at 
the  forefront  of  knowledge  in  defense 
acquisition  management  education 
through  long-term  inquiry  into  topics 
of  potential  importance  in  improving 
DOD  systems  acquisition  manage¬ 
ment.  Products  of  research  include 
classroom  experiences,  studies  for 
DOD  executives,  and  information  in 
publications  for  the  acquisition  man¬ 
agement  community.” 

The  Research,  Consulting  and  In¬ 
formation  Division  (RCID)  manages 
the  overall  program  of  applied  acqui¬ 


sition  research  at  the  College.  Research 
is  conducted  primarily  by  faculty  mem¬ 
bers  and  selected  students  and,  occa¬ 
sionally,  with  outside  professionals  in 
cooperative  major  emphasis  includ¬ 
ing  finding  ways  to  reduce  and  control 
system  acquisition  costs  more  effec¬ 
tively.  Current  RCID  endeavors  in¬ 
clude  the  following: 

—  The  Acquisition  Research  Sym¬ 
posium  is  a  series  of  conferences  that 
began  in  1972  and  is  conducted  bien¬ 
nially.  These  symposia  offer  a  dynamic 
forum  for  dialogue  among  key  profes¬ 
sionals  working  on  vital  issues  facing 
the  acquisition  community.  The  most 
recent  symposium  was  held  in  lune 
1993.  Planninghas  begun  forthe  1995 
symposium. 
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—  The  Military  Research  Fellow-  standardizationofthesecriticalterms,  research  capability.  The  Center,  es- 
ship  Program,  chartered  by  the  Under  to  answer  the  questions  posed  by  the  tablished  at  the  request  of  the  USDfA) 
Secretary  of  Defense  (Acquisition)  in  subcommittee  and  provide  recommen-  in  1992,  fills  a  void  as  the  only  central 
1987  to  enhance  DSMC  capabilities,  dations  for  legislation,  if  needed.  repository  of  defense  acquisition  in- 
provides  professional  military  educa-  formation  in  DOD.  (See  the  related 

tion  and  develops  new  and  innovative  — Through  a  unique  system  called  article  in  this  issue.) 

concepts  forsystemsacquisition  man-  Research  on  Ongoing  Acquisition  Re- 

agement.  This  joint  fellowship  pro-  search  (ROAR),  DSMC  is  beginning  to  As  the  Forum  continued.  Dr.  Rush 
gram  is  a  unique  opportunity  for  se-  reform  how  acquisition  policy  research  identified  processes  and  projects  to 
lected  officers  to  supplement  DSMC  products  are  developed  and  acquired  enhance  and  ensure  faculty  currency 
research  goals  and  to  impact  the  de-  bytheDOD.The  ROAR  monitors  more  in  acquisition  research.  Dr.  LaBerge 
fense  acquisition  process.  The  1993-  than  1,000  ongoing,  acquisition-re-  then  discussed  student  electives  and 
94  fellows  are  working  on  a  handbook  lated  study  projects  across  the  DOD  how  they  can  produce  the  most  up-to- 
for  program  managers  on  modeling  and  in  universities.  The  DSMC  uses  date  initiatives  in  the  acquisition  field, 
and  simulation.  Projected  availability  ROAR  information  to  tell  policy  mak- 

of  this  handbook  is  September  1994.  ers  and  researchers  who  embark  on  Mr.  Keightley  remarked  on  DAU 

new  projects  about  any  current  stud-  accomplishments  since  it  became  op- 
— The  Senate  Armed  Services  Sub-  ies  that  tie  into  the  projects.  This  al-  erational  one  year  ago  and  the  role  of 
committee  on  Defense  Technology,  lows  the  newcomer  to  collaborate,  DSMC  Press  as  publisher  of  the  new 
Acquisition  and  Industrial  Base  has  saving  the  DOD  months  of  valuable  Acquisition  Review  Quarterly.  He  also 
asked  DSMC  to  conduct  research  in  time  and  effort.  Other  databases  and  addressed  other  planned  assignments 
"defense  conversion”  and  “dual-use  on-line  services  cannot  do  what  ROAR  —  one  being  definition  of  a  role  for 
technologies.”  The  research  should  does  —  find  shortcuts  to  research  so-  DAU  in  acquisition  research, 
address  specifically  definitions,  bench-  lutions  for  unfolding  policy  problems. 

marks  and  metrics,  goals,  milestones.  The  Forum  ended  with  questions 

and  timetables.  The  RCID  is  conduct-  — The  DOD  Acquisition  Historical  and  answers  between  Mr.  Deutch, 

Ing  a  preliminary  structured  study  us-  Center  represents  significant  poten-  members  of  the  roundtable,  and  the 
ing  past  and  current  data  to  suggest  a  tial  as  part  of  the  DSMC  and  DAU  audience. 


STATEMENT  REQUIRED  BY  THE  ACT  OF  AUGUST  12,  1970,  SECTION  3685,  TITLE  39,  UNITED 
STATES  CODE,  SHOWING  THE  OWNERSHIP,  MANAGEMENT,  AND  CIRCULATION  OF 

Program  Manager,  published  bimonthly  at  the  Defense  Systems  Management  College,  Fort  Belvoir  VA  22060- 
5565.  Number  of  issues  published  annually:  6.  The  Director  of  the  DSMC  Press  is  Wilbur  D.  Jones,  Jr.,  DEFENSE 
SYSTMGMTCOLG,  ATTN  DSMC  PRESS,  9820  BELVOIR  ROAD,  SUITE  G38,  FT  BELVOIR  VA  22060-5565.  The 
Managing  Editor  is  Esther  M.  Farria,  DEFENSE  SYSTMGMTCOLG,  ATTN  DSMC  PRESS,  9820  BELVOIR  ROAD, 
SUITE  G38,  FT  BELVOIR  VA  22060-5565.  The  Publisher  is  the  Defense  Systems  Management  College,  Fort 
Belvoir  VA  22060-5565. 

The  average  number  of  copies  each  issue  during  the  The  actual  number  copies  of  single  issue  published 
preceding  12  months;  nearest  to  filing  date: 

A.  Total  number  of  copies  printed  (net  press  run):  9,833  A.  Total  number  of  copies  printed  (net  press  run): 

B.  Paid  and/or  requested  circulation:  1 ,3 16  15,000 

1.  Sales  through  dealers  and  carriers,  street  vendors,  B.  Paid  and/or  requested  circulation:  1,316 

and  counter  sales:  None  1.  Sales  through  dealers  and  carriers,  street  vendors, 

2.  Mail  subscriptions  paid  and/or  requested:  7,000  and  counter  sales:  None 

C.  Total  paid  and/or  requested  circulation:  8,316  2.  Mail  subscriptions  paid  and/or  requested:  12,100 

D.  Free  distribution  by  mail,  carrier,  or  other  means,  C.  Total  paid  and/or  requested  circulation:  13,416 
samples,  complimentary,  and  other  free  copies:  1,500  D.  Free  distribution  by  mail,  carrier,  or  other  means, 

E.  Total  distribution:  9,816  samples,complimentary,andotherfreecopies;  1,500 

F.  Copies  not  distributed  E.  Total  distribution:  14,916 

1.  -Office  use,  leftover,  unaccounted,  spoiled  after  F.  Copies  not  distributed 

printing:  17  1.  Office  use,  leftover,  unaccounted,  spoiled  after 

2.  Returns  from  news  agents:  None  printing:  84 

G.  Total  distribution;  9,833  2.  Returns  from  news  agents:  None 

G.  Total  distribution:  15,000 


Program  Manager 


39 


Jonuory-Februory  1994 


DEPSECDEF  TO  GRADUATES 


TILTING  AT  THE  WINDMILL  OF 
DEFENSE  ACQUISITION  REFORM 


ii  ’m  committed  to  restructuring  the 
acquisition  system  for  a  different 
environment,  but  to  succeed  1 
,  .  need  your  help.”  This  was  the 
messageof  Dr.  William  f.  Perry,  Deputy 
Secretary  of  Defense,  to  graduating 
PMC  class  93-2,  at  graduation  cer¬ 
emonies  on  December  10,  1993. 


In  a  keynote  Un January  24, 

address  that  high-  announced  his 

lightedchangesin  nate  Dr.  Wil 

world  conditions,  succeed  Les  As 

Dr.  Perry  con-  Defense, 

gratulated  the  I— — 
class  on  its  accomplishments.  He 
stated  that  the  goal  of  all  their  hard 
work  was  to  make  them  better  manag¬ 
ers  to  work  in  the  Defense  De¬ 
partment’s  acquisition  system,  that 
the  training  DSMC  had  given  them 
was  as  good  as  any  in  the  world,  but 
that  they  were  going  to  need  all  the 
knowledge  gained  to  help  them  man¬ 
age  a  transition  to  a  new  post-Cold 
War  acquisition  system.  Dr.  Perry  re¬ 
ferred  to  a  recent  best-selling  book 
which  had  proclaimed  the  “end  of 
history,”  and  said,  “Headlines  show 
that  history  is  still  being  written  in 
places  like  Pyongyang,  Mogadishu,  or 
Sarajevo.  These  headlines  remind  us 
that  we  still  face  difficult  and  complex 
problems  and  that  we  will  need  to 
maintain  the  technological  edge  which 
we  demonstrated  in  Desert  Storm  if 


Ms.  Dellinger  is  a  Professor  of  Sys¬ 
tems  Acquisition  Management  in  the 
Research,  Consulting  and  Information 
Division,  DSMC.  The  editor  thanks 
Ms.  Janice  Baker,  DSMC,  for  her  assis¬ 
tance  on  this  article. 


Lyn  Dellinger 

we  get  in  another  military  conflict  in 
the  near  future.” 

But  while  that  necessity  remains. 
Dr.  Perry  projects  a  reduction  in  the 
defense  procurement  budget  by  1997 
of  about  60-65  percent  of  its  peak  in 
the  1980s.  He  said  the  challenge  is  to 
'  n  “find  a  way  of 


On  January  24, 1994,  the  President 
announced  his  intention  to  nomi¬ 
nate  Dr.  William  J.  Perry  to 
succeed  Les  Aspin  as  Secretary  of 
Defense. 


y^'t.uici'resiuciii  maintaining 
ntention  to  nomi-  the  industrial 
iam  J.  Perry  to  base  which 
in  as  Secretary  of  gave  us  the 
technological 
^  advantage....We 
have  to  do  this  at  a  reduced  cost,  and 
therefore,  we  have  to  find  more  effi¬ 
cient  ways  of  doing  it.” 

Quoting  Professor  Theodore 
Leavitt,  who  said,  “Most  managers 
manage  for  yesterday’s  conditions  be¬ 
cause  yesterday  is  where  they  got  their 
experiences  and  had  their  successes,” 
Dr.  Perry  added  that  “management  is 
about  tomorrow,  not  yesterday.  ”  Con¬ 
sequently,  he  is  projTosing  a  radical 
revamping  of  the  Department  of  De¬ 
fense  acquisition  system.  He  said, 
“...we  must  take  dramatic  action  to 
integrate  the  defense  industrial  base 
with  the  commercial  industrial  base 
so  that  we  create  a  single  national 
industrial  base  —  a  single  national 
technology  base.”  He  pointed  out  that 
the  existing  system,  which  evolved 
over  the  past  five  decades,  separates 
the  defense  base  from  the  national 
base  through  unique  contracting  pro¬ 
cesses,  unique  process  and  product 
specifications  and  standards,  and 
unique  security  procedures.  “My  ob¬ 
jective,”  he  pledged,  "will  be  to  have 
the  Defense  Department  evolve  to  a 


IS®  A  ■■  ■!*  ■ 
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fundamentally  new  acquisition  sys¬ 
tem  based  on  commercial  practices.” 

To  accomplish  his  goals,  Congress 
must  provide  legislative  relief  from 
regulations  that  have  created  many  of 
the  obstacles  to  reform  of  the  acquisi¬ 
tion  system.  But,  there  is  support  in 
the  Congress.  In  1994,  the  House  and 
the  Senate  will  debate  bills  that  would 
make  substantial  changes  in  defense 


acquisition  practices,  to  include  al¬ 
lowing  commercial  procurement  prac¬ 
tices  for  procuring  commercial  prod¬ 
ucts,  raising  the  threshold  to  $  100,000 
under  which  DOD  could  use  simpli¬ 
fied  procurement  procedures,  and  sim- 
piifying  reporting  requirements  for  op¬ 
erational  testing.  In  Dr.  Perry’s  view, 
these  are  important  steps,  but  are  still 
short  of  what  he  deems  necessary.  He 
wants  to  broaden  the  definition  of 
commercial  products,  exempt  com¬ 
mercial  products  automatically  from 


have  mounted  my  steed,  I  have  my 
lance  under  my  arm,  and  I'm  galloping 
ahead  full  speed  toward  that  windmill. 

Dr.  William  J.  Perry 


cost  and  pricing  requirements,  and 
reduce  even  further  the  number  of 
unique  requirements  the  government 
specifies  for  items  it  purchases. 


(Acquisition  Reform),  headed  by  Mrs. 
Colleen  A.  Preston,  to  work  with  teams 
within  DOD.  As  an  example  of  this 
effort.  Dr.  Perry  mentioned  the  search 
for  feasible  alternatives  to  MILSPECS 
on  defense  systems,  concentrating  on 
near-term,  high-payoff  changes  —  a 
search  which  has  already  resulted  in  a 
new  electronic  procurement  notice  and 
payment  system. 

Dr.  Perry  admitted  the  task  that  lies 
ahead  is  daunting,  and  skeptics  ques¬ 
tion  whether  DOD  can  break  its  old 
bad  habits.  To  scoffers.  Dr.  Perry 
quoted  Winston  Churchill,  who  told 
an  aide  who  complained  of  the  exas¬ 
perating  ways  Americans  have  of  do¬ 
ing  things,  “Americans  will  always  do 
the  right  thing  after  having  first  ex¬ 
hausted  all  other  alternatives.” 

Dr.  Perry  concluded  by  confiding 
that  he  had  been  told  often  that  he 
should  stop  tilting  at  the  windmill  of 
acquisition  reform.  “But,”  he  said,  “I 
have  mounted  my  steed,  1  have  my 
lance  under  my  arm,  and  I’m  gallop¬ 
ing  ahead  full  speed  toward  that  wind¬ 
mill.  I  ask  you  to  join  me  in  that  quest 
to  break  down  the  costly  barriers  in 
our  system  and  create  a  new  acquisi¬ 
tion  system  to  provide  the  finest  equip¬ 
ment  for  our  forces  at  a  cost  the  nation 
can  afford.” 
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DEFENSE 

ACQUISITION 

REFORM 

SYMPOSIUM 

APRIL  26.  1994 

Fort  Lesley  J.  McNair, 
Washington,  D.C. 

Hosted  by 

The  National  Defense  University, 
The  Defense  Acquisition  Univer¬ 
sity,  The  Industrial  College  of  the 
Armed  Forces  (ICAF),  and  The 
John  M.  Olin  Institute  for  Strategic 
Studies,  Harvard  University 

Sponsored  by 

American  Defense  Preparedness 
Association  (ADPA)  Association  of 
the  Industrial  College  of  the 
Armed  Forces 

This  symposium  is  a  follow-on  to 
the  1993  ICAF  Symposium  “Gov¬ 
ernment,  Industry,  and  Academia: 
Partnership  for  a  Competitive 
America.”  There  was  a  consensus 
among  the  panelists  at  that  sympo¬ 
sium  that  these  three  sectors  of  our 
society  will  find  a  way  to  work  to¬ 
gether  to  ensure  a  competitive 
America.  One  of  the  essential  areas 
of  cooperation  is  the  acquisition  pro¬ 
cess.  As  we  shift  to  a  new  era  of 
fewer  resources,  it  is  necessary  that 
the  acquisition  process  be  more  ef¬ 
ficient  and  effective.  The  process  of 
the  reform  of  the  system  must  be  a 
cooperative  enterprise  in  which  gov¬ 
ernment  and  industry  work  together 
in  a  true  partnership.  The  April  26, 
1994,  symposium  will  provide  a  fo¬ 
rum  for  representatives  from  those 
sectors  to  engage  in  open  and  can¬ 
did  dialogue  about  a  strategy  for 
genuine  acquisition  reform. 

Registration  information  will  be 
available  in  the  February-March 
time  frame.  To  be  put  on  the  mailing 
list,  contact: 

ADPA 

Attn:  Ms.  Mary  Murphy 
2102  Wilson  ^ulevard.  Suite  400 
Arlington,  VA  22201 
(703)  247-2582 


BOOK  REVIEW 


BEYOND  SPINOFF 
Military  and  Commercial 
Technologies  in  the 
Changing  World 


Harvard  Business  School  Press 

by  John  A.  Alic,  Lewis  M.  Branscomb, 
Harvey  Brooks,  Ashton  B.  Carter  and 
Gerald  L.  Epstein 


The  authors  are  associated  with 
the  Science ,  Technology  and  Pub¬ 
lic  Policy  Program  (STPP)  at  the  Cen¬ 
ter  for  Science  and  International  Af¬ 
fairs,  John  F.  Kennedy  School  of  Gov¬ 
ernment,  Harvard  University.  They 
have  significant  government,  policy, 
technology  and  academic  experience. 
Their  treatment  of  the  subject  of  dual- 
use;  i.e.,  utilization  of  defense  tech¬ 
nology  for  commercial  applications, 
presents  a  timely  and  detailed  discus¬ 
sion  of  issues  and  policy  consider¬ 
ations.  Technology  transfer  from  gov¬ 
ernment  to  civil  spin-off,  as  well  as 
civil  to  government  “spin-on”  are  ad¬ 
dressed. 

Many  think  the  present  shrinking 
industrial  base  offers  little  opportu¬ 
nity  for  exploitation  of  commercial 
markets.  How  many  nuclear  subma¬ 
rines  can  you  sell  to  the  commercial 
sector?  The  authors  do  not  suggest 
that  this  type  of  dual-use  or  spin-off 
will  happen.  They  do  not  paint  a  pic¬ 
ture  that  the  next  few  years  will  be 
easy  for  defense  firms.  They  do,  how¬ 
ever,  point  out  that  many  defense  tech¬ 
nologies  can  be  transferred  success¬ 
fully  to  commercial  applications.  They 
cite  manufacturing  technologies  (nu¬ 
merical  control  machining,  CAD/CAM , 
composites,  etc.)  as  being  prime  can¬ 
didates  for  spin-off  to  commercial  ap¬ 
plications. 

Microelectronics  and  software  ex¬ 
amples  for  spin-off  and  spin-on  re¬ 
ceive  a  lengthy  examination.  The  Very 
High  Speed  Integrated  Circuit  ( VHSIC) 
was  an  Office  of  the  Secretary  of  De¬ 
fense  (OSD)  research  and  develop¬ 


ment  (R&D)  effort  to  foster  technology 
transfer  from  commercial  and  defense 
companies  to  defense  applications. 
From  a  technology  standpoint;  e.g., 
image  size,  some  considered  VHSIC  a 
limited  success.  However,  technolog'/ 
transfer  goals  of  the  program  were 
elusive. 

The  program  was  managed  by  OSD 
with  the  intent  that  the  Services  would 
use  the  VHSIC  chips  in  their  programs. 
The  Army,  Navy  and  Air  Force  weren’t 
convinced  the  chips  would  help  them, 
especially  in  mature  weapon  systems. 
There,  the  major  failure  of  the  program 
was  that  little  actual  technology  inser¬ 
tion  was  achieved. 

This  lesson  should  be  kept  in  mind 
when  our  present  leadership  thinks  of 
developing  future  technology  and  then 
putting  it  "on  the  shelf.”  The  authors 
recommend  that  the  Pentagon  find  a 
way  to  reduce  disincentives  driving 
commercial  firms  away  from  defense 
business.  Simultaneous  engineering 
should  be  the  incentive  so  future  tech¬ 
nologies  will  be  more  manufacturable 
and  maintainable;  accounting  proce¬ 
dures  and  regulations  changed  so  firms 
are  not  prohibited  from  integrating 
government  and  commercial  busi¬ 
nesses;  and,  military  specifications  and 
standards  brought  into  agreement  with 
commercial  best  practices  if  spin-off 
and  spin-on  are  to  be  achieved. 

This  book  should  be  on  the  desk  of 
every  serious  student  of  the  industrial 
base  and  global  competitiveness. 

Jack  McGovern,  Professor, 
Manufacturing  Management 
Department,  DSMC 
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TOOLS  OF  THE  TRADE 

A  Workman’s  Bag 

Michael  L.  Tompkins 


A  workman  has  a  bag  of  tools.  He 
begins  his  career  with  shiny  new 
ones  made  of  polished  chrome 
and  plastic.  He  digs  through  all 
of  them  to  find  the  ones  he  needs  for 
his  first  job.  Then,  he  begins  his  career 
with  the  turn  of  a  shiny  new  wrench  or 
a  new  screwdriver.  Over  time,  the  tools 
he  uses  most  often  will  accumulate  at 
the  top  of  the  bag,  and  the  others, 
depending  upon  the  occurrence  of  their 
use,  will  become  stratified  toward  the 
bottom.  As  they  move  down,  they  will 
become  dull  and  a  few  will  even  rust 
from  lack  of  use.  Some  tools  will  never 
be  used,  though  the  workman  has 
made  a  significant  cash  investment  in 
them,  too. 

As  time  passes,  the  tools  he  uses 
most  will  wear  out  and  be  replaced.  A 
few  special  tools  will  be  added  to  the 
bag,  and  the  workman  may  even  de¬ 
sign  and  build  some  new  tools  for 
himself  to  make  some  of  his  work 
easier.  Throughout  bis  career,  the 
workman  will  carry  his  bag  of  tools 
with  him.  All  of  the  tools  with  which  he 
began  his  career  are  still  in  it,  though 
some  are  forgotten  and  never  used. 

Accumulating  Useful  Tools 

Skills  and  knowledge  that  are  ac¬ 
quired  over  time  are  useful  tools.  Some 
become  forgotten  because  they  are 


Mr.  Tompkins  is  Production  Man¬ 
agement  Specialist,  Contractor  Logis¬ 
tics  Support  Division,  Air  Logistics  Cen¬ 
ter,  Tinker  AFB,  Oklahoma  City,  Okla. 


seldom  or  never  used  in  our  daily 
lives.  The  ones  we  use  most  will  quickly 
become  a  part  of  our  routines.  Others, 
because  they  achieve  the  needed  or 
desired  results,  will  be  added  to  the 
top  of  our  bags.  Without  our  set  of 
tools  we  are  incapable;  with  them,  we 
can  do  great  things. 

People  and  organizations  tend  to 
push  some  of  their  tools,  or  skills, 
knowledge,  capabilities,  and  even 
some  of  their  employees  toward  the 
bottom  of  the  tool  bag  where  they  are 
forgotten  from  lack  of  use.  This  is  from 
being  in  a  routine  of  using  only  tools 
and  people  that  produce  results  and 
personal  or  organizational  rewards. 
Occasionally,  new  tools  suit  only  rou¬ 
tine  needs,  and  produce  little  real  ben¬ 
efit.  These  tools,  too,  tend  to  be  adopted 
and  added  to  the  top  of  the  bag  be¬ 
cause  they  are  used  frequently. 

How  often  have  we  pulled  a  book  of 
regulations  from  the  shelf  and  found 
in  it  things  we  suddenly  remembered 
were  there  and  were  needed  to  accom¬ 
plish  our  task? 

How  often  have  we  gone  through 
old  files  and  found  Information  that 
helped  us  solve  a  problem? 

How  often  have  we  talked  to  a 
colleague  and  discovered  he  or  she 
knew  something  that  proved  helpful? 
And,  how  often  have  we  done  some¬ 
thing  that  was  routine  and  found  out 
later  it  was  wrong;  we  hadn’t  bothered 
to  read  germane  information  or  re¬ 
search  the  facts? 


How  Good  Are  They? 

For  skills  and  knowledge  to  be  use¬ 
ful  they  must  be  kept  current  and 
accurate,  and  they  must  be  used  or 
time  will  dull  their  “shine.”  This  re¬ 
quires  constant  awareness  of  chang¬ 
ing  events  and  persistent  personal  ef¬ 
fort.  We  can  drift  easily  into 
comfortable  routines  that  require  the 
same  tools  every  day  and  little  effort. 
Over  time,  many  of  the  tools  we  carry 
eventually  will  become  rusted  and  for¬ 
gotten  from  lack  of  use.  This  is  espe¬ 
cially  true  in  government  service  where 
we  are  not  as  driven  by  the  forces  of 
"the  market,”  the  press  of  competi¬ 
tion,  and  the  dynamics  imposed  by 
constant  change.  New  tools  are  given 
to  us  daily  in  the  form  of  information, 
personnel  and  organizational  changes 
around  us,  and  training.  All  of  the  old 
tools  are  still  there,  too,  though  they 
may  have  become  dull  and  forgotten 
from  lack  of  use. 

Use  Keeps  Them  New 

As  organizations  and  as  individu¬ 
als  we  are  all  workmen  in  our  trade, 
and  we  will  always  carry  our  bags  full 
of  tools  in  the  form  of  our  accumulated 
knowledge,  skills,  and  our  or¬ 
ganization’s  capabilities.  If  we  are 
aware  only  of  the  tools  at  the  top,  the 
ones  we  use  most  often,  we  will  miss 
the  capabilities  and  the  opportunities 
the  remaining  tools  offer.  We  must 
keep  an  inventory  of  what  we  have  so 
we  know  all  that  our  many  tools  can 
help  us  to  achieve.  We  must  be  aware 
constantly  of  opportunities  to  use  the 
tools  we  have  so  none  will  ever  be  lost, 
wasted  or  forgotten. 
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FROM  THE  COMMANDANT 


^Ketings  again.  Since  I  last  talked  with  you,  I 
^Biave  had  the  opportunity  to  see  a  large  por- 
^Btion  of  our  DOD  and  see  firsthand  the  fruits 
\J  of  our  acquisition  process.  I  recently  partici¬ 
pated  in  the  NDU  Capstone  course.  This  congres- 
sionally-mandated  course  is  required  for  ail  new 
general  and  flag  officers.  The  purpose  of  the  course 
is  to  expose  these  officers  to  ail  aspects  of  the 
DOD,  our  federal  government  and  selected  for¬ 
eign  governments,  to  include  views  from  senior 
leaders,  pressing  issues  and  the  workings  of  key 
processes.  Several  thoughts  regarding  our  acquisi¬ 
tion  process  occurred  to  me  during  this  course, 
and  I’d  like  to  share  a  few  of  them  with  you. 

The  first  thing  that  struck  me  was  how  much  the 
DOD  military  has  institutionalized  joint  opera¬ 
tions.  All  of  our  military  services  are  actively 
engaged  in  integrating  their  o[)erations.  Changes 
in  training  concepts  give  excellent  examples.  The 
Army  National  Training  Center,  Fort  Irwin,  Calif., 
and  the  Air  Warrior  at  Nellis  AFB,  Nev.,  have 
integrated  their  efforts  to  provide  realistic  air-land 
battles.  Both  Red  and  Blue  army  commanders  call 
upon  air  forces  to  support  ground  objectives  using 
established,  real-world,  joint  procedures.  Thus, 
the  Army  and  Air  Force  get  a  great  opportunity  to 
train  the  way  they  will  fight  —  “joint.”  Other 
training  examples  find  the  Air  Force  Red  Flag,  the 
Navy  Top  Gun  and  Navy  Falon  participating  in 
each  other’s  exercises  as  well  as  updating  and 
integrating  their  training  ranges.  The  recent  Ocean 
Venture  exercise  conducted  in  the  Caribbean  pro¬ 
vided  not  only  an  example  of  U.S.  joint  operations 
but,  also,  coalition  operations  since  other  coun¬ 
tries  participated. 

These  are  only  a  small  fraction  of  the  changes 
in  how  our  forces  conduct  their  operations.  What 
does  all  this  mean  to  us?  First,  we  as  “acquisition 
types”  need  to  realize  this  has  happened  and  our 
users  and  their  requirements  will  and  have  changed 
in  response.  As  we  review  requirements,  we  need 
to  ask  our  user  and  ourselves  “what  are  the  joint 


implications.  This  is  particularly  important  when 
we  work  the  C4I  systems.  In  fact,  C4I  can  no 
longer  be  considered  as  a  separate  acquisition  if 
we  are  to  maintain  the  system  management  as¬ 
pect  of  our  acquisition;  particularly,  joint  pursu¬ 
ing  will  be  impossible  without  due  thought  to  joint 
requirements.  Integrating  the  Air  Forces  Red  Flag, 
the  Navy  Falon  and  Top  Gun  training  ranges 
requires  significant  attention  to  joint  requirements. 
Integration  of  battle/campaign  simulations  from 
various  military  installations  around  the  country 
require  the  same  attention. 

Special  operations  forces,  also  known  as  “spe¬ 
cial  ops,”  are  not  exempted  and  may  be  a  micro¬ 
cosm  of  what  will  be  demanded  of  our  acquisition 
process  in  the  future.  Special  ops  effectively  com¬ 
bine  air,  land  and  sea  forces  to  accomplish  their 
mission.  Typically,  the  special  ops  requirements 
are  very  demanding  from  both  a  joint  prospective 
as  well  as  an  extremely  compressed  schedule  or 
IOC  prospective.  To  a  large  degree,  many  of  us  are 
excluded  from  the  special  ops  acquisition  process 
because  we  do  not  understand  the  special  ops 
requirements.  Even  if  we  did,  our  process  is  not 
viewed  as  being  responsive  to  the  special  ops 
needs;  particularly,  the  short  acquisition  time 
lines  often  required.  Increasing  our  efforts  to  fully 
meet  the  special  ops  requirements  would  go  a 
long  way  in  addressing  the  joint  requirements  as 
well  as  adding  value  to  the  special  ops  acquisition 
process. 

These  are  a  few  thoughts  on  how  1  believe  our 
acquisition  process  will  be  asked  to  change  in  the 
future.  Other  immediate  changes  are  taking  place 
and  I  will  pass  those  on  to  you  in  future  Program 
Manager  articles.  One  of  the  most  interesting  will 
be  the  improved  and  shortened  PMC  to  debut  95- 
I.  More  on  that  and  other  changes  next  time. 

— Brig  Gen  (Sel.)  Claude  M.  Bolton,  )r., 
USAF 
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